Giter VIP home page Giter VIP logo

graphbrainz's Introduction

GraphBrainz

build status coverage npm version license

A GraphQL schema, Express server, and middleware for querying the MusicBrainz API. It features an extensible schema to add integration with Discogs, Spotify, Last.fm, fanart.tv, and more!

Try out the live demo! 💡 Use the “Docs” sidebar, the schema, or the types docs to help construct your query.

Support

Did this project bring you joy? Want to support updates? Check out my GitHub Sponsors page.

Alternatively…

Buy Me A Coffee

Install

Install with npm:

npm install graphbrainz --save

Install with Yarn:

yarn add graphbrainz

GraphBrainz is written and distributed as native ECMAScript modules (ESM) and requires a compatible version of Node.js

Contents

Usage

This package can be used both as a standalone GraphQL server and as Express middleware supplying a GraphQL endpoint.

As a standalone server

Run the included graphbrainz executable to start the server. The server is configured using environment variables.

$ graphbrainz
Listening on port 3000.

Development mode features like JSON pretty printing and the GraphiQL interface will be enabled unless the server is run with NODE_ENV=production.

Note that if you are not running the standalone server within another Node project, you may wish to install this package globally so that the graphbrainz script is globally available:

npm install -g graphbrainz

As middleware

If you have an existing Express server and want to add this GraphQL service as an endpoint, or you just want more customization, use the middleware.

import express from 'express';
import { middleware as graphbrainz } from 'graphbrainz';

const app = express();

// Use the default options:
app.use('/graphbrainz', graphbrainz());

// or, pass some options:
app.use('/graphbrainz', graphbrainz({
  client: new MusicBrainz({ ... }),
  graphiql: true,
  ...
}));

app.listen(3000);

The graphbrainz middleware function accepts the following options:

  • client: A custom API client instance to use. See the client submodule for help with creating a custom instance. You probably only need to do this if you want to adjust the rate limit and retry behavior.
  • Any remaining options are passed along to the standard GraphQL middleware. See the express-graphql documentation for more information.

As a client

If you just want to make queries from your app without running a separate server or exposing a GraphQL endpoint, use the GraphBrainz schema with a library like GraphQL.js. You just need to create the context object that the GraphBrainz resolvers expect, like so:

import { graphql } from 'graphql';
import { MusicBrainz, createContext, baseSchema } from 'graphbrainz';

const client = new MusicBrainz();
const context = createContext({ client });

graphql(
  schema,
  `
    {
      lookup {
        releaseGroup(mbid: "99599db8-0e36-4a93-b0e8-350e9d7502a9") {
          title
        }
      }
    }
  `,
  null,
  context
)
  .then((result) => {
    const { releaseGroup } = result.data.lookup;
    console.log(`The album title is “${releaseGroup.title}”.`);
  })
  .catch((err) => {
    console.error(err);
  });

Environment Variables

  • MUSICBRAINZ_BASE_URL: The base MusicBrainz API URL to use. Change this if you are running your own MusicBrainz mirror. Defaults to http://musicbrainz.org/ws/2/.
  • GRAPHBRAINZ_PATH: The URL route at which to expose the GraphQL endpoint, if running the standalone server. Defaults to /.
  • GRAPHBRAINZ_CORS_ORIGIN: The value of the origin option to pass to the CORS middleware. Valid values are true to reflect the request origin, a specific origin string to allow, * to allow all origins, and false to disable CORS (the default).
  • GRAPHBRAINZ_CACHE_SIZE: The maximum number of REST API responses to cache. Increasing the cache size and TTL will greatly lower query execution time for complex queries involving frequently accessed entities. Defaults to 8192.
  • GRAPHBRAINZ_CACHE_TTL: The maximum age of REST API responses in the cache, in milliseconds. Responses older than this will be disposed of (and re-requested) the next time they are accessed. Defaults to 86400000 (one day).
  • GRAPHBRAINZ_GRAPHIQL: Set this to true if you want to force the GraphiQL interface to be available even in production mode.
  • GRAPHBRAINZ_EXTENSIONS: A JSON array of module paths to load as extensions.
  • PORT: Port number to use, if running the standalone server.

When running the standalone server, dotenv is used to load these variables from a .env file, if one exists in the current working directory. This just makes it more convenient to launch the server with certain settings. See the dotenv package for more information.

Debugging

The DEBUG environment variable can be used to enable logging for all (or just some) of this package’s submodules:

$ DEBUG=graphbrainz:* graphbrainz

See the debug package for more information.

Example Queries

Nirvana albums and each album’s singles (try it):

query NirvanaAlbumSingles {
  lookup {
    artist(mbid: "5b11f4ce-a62d-471e-81fc-a69a8278c7da") {
      name
      releaseGroups(type: ALBUM) {
        edges {
          node {
            title
            firstReleaseDate
            relationships {
              releaseGroups(type: "single from") {
                edges {
                  node {
                    target {
                      ... on ReleaseGroup {
                        title
                        firstReleaseDate
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Pagination

The first five labels with “Apple” in the name (try it):

query AppleLabels {
  search {
    labels(query: "Apple", first: 5) {
      ...labelResults
    }
  }
}

fragment labelResults on LabelConnection {
  pageInfo {
    endCursor
  }
  edges {
    cursor
    node {
      mbid
      name
      type
      area {
        name
      }
    }
  }
}

…and the next five, using the endCursor from the previous result (try it):

query AppleLabels {
  search {
    labels(query: "Apple", first: 5, after: "YXJyYXljb25uZWN0aW9uOjQ=") {
      ...labelResults
    }
  }
}

Who the members of the band on an Apple Records release married, and when (try it):

query AppleRecordsMarriages {
  search {
    labels(query: "Apple Records", first: 1) {
      edges {
        node {
          name
          disambiguation
          country
          releases(first: 1) {
            edges {
              node {
                title
                date
                artists {
                  edges {
                    node {
                      name
                      ...bandMembers
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

fragment bandMembers on Artist {
  relationships {
    artists(direction: "backward", type: "member of band") {
      edges {
        node {
          type
          target {
            ... on Artist {
              name
              ...marriages
            }
          }
        }
      }
    }
  }
}

fragment marriages on Artist {
  relationships {
    artists(type: "married") {
      edges {
        node {
          type
          direction
          begin
          end
          target {
            ... on Artist {
              name
            }
          }
        }
      }
    }
  }
}

Images of Tom Petty provided by various extensions (try it):

query TomPettyImages {
  lookup {
    artist(mbid: "5ca3f318-d028-4151-ac73-78e2b2d6cdcc") {
      name
      mediaWikiImages {
        url
        objectName
        descriptionHTML
        licenseShortName
      }
      fanArt {
        thumbnails {
          url
          likeCount
        }
      }
      theAudioDB {
        logo
        biography
      }
    }
  }
}

You can find more example queries in the schema tests.

Questions

What’s with the cumbersome edges/node nesting? Why first/after instead of limit/offset? Why mbid instead of id?

You can thank Relay for that; these are properties of a Relay-compliant schema. The schema was originally designed to be more user-friendly, but in the end I decided that being compatible with Relay was a worthwhile feature. I agree, it’s ugly.

The GraphBrainz schema includes an extra nodes field on every connection type. If you only want the nodes and no other fields on edges, you can use nodes as a shortcut.

Don’t forget that you can also use GraphQL aliases to rename fields to your liking. For example, the following query renames edges, node, and mbid to results, releaseGroup, and id, respectively:

query ChristmasAlbums {
  search {
    releaseGroups(query: "Christmas") {
      results: edges {
        releaseGroup: node {
          id: mbid
          title
        }
      }
    }
  }
}

Why does my query take so long?

It’s likely that your query requires multiple round trips to the MusicBrainz REST API, which is subject to rate limiting. While the query resolver tries very hard to fetch only the data necessary, and with the smallest number of API requests, it is not 100% optimal (yet). Make sure you are only requesting the fields you need and a reasonable level of nested entities – unless you are willing to wait.

You can also set up a local MusicBrainz mirror and configure GraphBrainz to use that with no rate limiting.

Schema

The types document is the easiest to browse representation of the schema, or you can read the schema in GraphQL syntax.

Extending the schema

The GraphBrainz schema can easily be extended to add integrations with third-party services. See the Extensions docs for more info.

graphbrainz's People

Contributors

exogen avatar greenkeeper[bot] avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

graphbrainz's Issues

Batch lookup queries using the search endpoint with ID fields

I've been running a large amount of complex queries, and often it's the case that deeply nested results lead to lots of individual lookup queries for entities.

I hacked up a proof-of-concept that uses dataloader's batching feature to recognize such lookups and make them using the search endpoint.

e.g. /ws/2/recording?query=rid:"{MBID}" OR rid:"{MBID}" OR ...

Then it will automatically map the results to the original, individual lookup requests, so they don't even know a different endpoint was used.

It works surprisingly well. The search endpoint also tends to return more data for each entity by default. This can speed up queries by 20–50x and avoid waiting for rate limits to clear up.

I'm planning on a rewrite of the whole GraphBrainz "query engine" to support this.

An in-range update of sinon is breaking the build 🚨

Version 2.3.6 of sinon just got published.

Branch Build failing 🚨
Dependency sinon
Current Version 2.3.5
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As sinon is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Status Details
  • continuous-integration/travis-ci/push The Travis CI build passed Details
  • coverage/coveralls First build on greenkeeper/sinon-2.3.6 at 99.334% Details
  • ci/circleci A command timed out during your tests Details

Commits

The new version differs by 30 commits.

  • 496f6b0 Update docs/changelog.md and set new release id in docs/_config.yml
  • 60a3284 Add release documentation for v2.3.6
  • 98119bf 2.3.6
  • 4f07053 Update Changelog.txt and AUTHORS for new release
  • 1fc4d59 Experiment over
  • 13e11c8 Experiment: Object.defineProperty(winodw, 'innerHeight'), Safari 10 - part 3
  • 76dd323 Experiment: Object.defineProperty(winodw, 'innerHeight'), Safari 10 - part 2
  • 83e84a9 Experiment: Object.defineProperty(winodw, 'innerHeight'), Safari 10
  • 6adba15 Merge pull request #1473 from fearphage/eslint-yaml
  • e1d188c fixed capitalization
  • d22eda3 Merge pull request #1313 from takasmiley/issues/#1274
  • 1661a0f Add test code of spy.matchingFakes
  • cf3a34e Move #1274 test code to respective test files
  • 833ff2c Replace for loop with Array.prototype.forEach
  • e72fee4 Update matchingFakes, always returns array

There are 30 commits in total.

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Potential expansion to be less MusicBrainz-centric

Currently, most of the extensions depend on being attached to a particular MusicBrainz entity, and don't offer many of their own fields on the root Query.

I'm considering rebranding this project to something like "MusiQL", which would be very similar, but not MusicBrainz-centric. Most of the existing queries would work exactly the same, but be under a musicBrainz field on the root query.

NPM Install Discogs extension on Heroku deploy does not work

With the latest fixes to update packages I am able to deploy successfully to Heroku now, thank you. However, I wish to use the Discogs extension.

The installation details state to just run npm install graphbrainz-extension-discogs but doing so on the Heroku console results in a lot of console logs stating Integrity checksum failed when using sha1.... and listing Discogs as an extension in the config vars does not work, probably because it cannot find it if it was installed.

How could I go about installing and using this extension? I would create a discussion on this topic and not an issue but I do not see this option for the repo. Thank you in advance!

WikiData extension

Use the wikidata URL relationship to query WikiData for more information.

An in-range update of babel-preset-es2015 is breaking the build 🚨

Version 6.24.1 of babel-preset-es2015 just got published.

Branch Build failing 🚨
Dependency babel-preset-es2015
Current Version 6.24.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-es2015 is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • ci/circleci Your tests failed on CircleCI Details

  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • coverage/coveralls First build on greenkeeper/babel-preset-es2015-6.24.1 at 99.334% Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Media tracks

Is it possible to retrieve all of the tracks on a Release? Looking at the MusicBrainz API it should be possible to do this:

{
  lookup {
    release(mbid: "617908f2-7a0b-3aad-ae02-5a5c125fa1a7") {
      media {
        trackCount
        position
        tracks # Cannot query field "tracks" on type "Medium"
        formatID
        format
      }
    }
  }
}

This is the equivalent request on the JSON web service: http://musicbrainz.org/ws/2/release/617908f2-7a0b-3aad-ae02-5a5c125fa1a7?inc=recordings&fmt=json

{
  "id": "617908f2-7a0b-3aad-ae02-5a5c125fa1a7",
  "media": [
    {
      "track-count": 12,
      "position": 1,
      "track-offset": 0,
      "tracks": [{}],
      "format-id": "9712d52a-4509-3d4b-a1a2-67c88c643e31",
      "format": "CD"
    }
  ]
}

How to access relationship URLs

https://musicbrainz.org/artist/e01646f2-2a04-450d-8bf2-0d993082e058/relationships

I want to pull the instagram URL of this band, so I wrote a query like:

  lookup {
    artist(mbid: "e01646f2-2a04-450d-8bf2-0d993082e058") {
      id
      mbid
      name
      sortName
      relationships {
        urls {
          edges {
            node {
              sourceCredit
              targetCredit
              begin
              end
              ended
              type
              typeID
              attributes
              direction
            }
          }
        }
      }
    }
  }

But I don't see any way of getting the title and URL of the relationship. Any insight?

Thanks for an amazing library, it really is super helpful.

Wikipedia extension

Use the wikipedia URL relationship to query Wikipedia for more information, using the MediaWiki API.

An in-range update of babel-preset-stage-2 is breaking the build 🚨

Version 6.24.1 of babel-preset-stage-2 just got published.

Branch Build failing 🚨
Dependency babel-preset-stage-2
Current Version 6.22.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-stage-2 is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • ci/circleci Your tests failed on CircleCI Details

  • coverage/coveralls First build on greenkeeper/babel-preset-stage-2-6.24.1 at 99.334% Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Demo query returns error

The sample query in the demo:

{
  lookup {
    artist(mbid: "5ca3f318-d028-4151-ac73-78e2b2d6cdcc") {
      name
      mediaWikiImages {
        url
        objectName
        descriptionHTML
        licenseShortName
      }
    }
  }
}

returns

{
  "errors": [
    {
      "message": "certificate has expired",
      "locations": [
        {
          "line": 5,
          "column": 7
        }
      ],
      "path": [
        "lookup",
        "artist",
        "mediaWikiImages"
      ]
    }
  ],
  "data": {
    "lookup": {
      "artist": null
    }
  }
}

Relationship helpers extension

Instead of making people access information through the somewhat cumbersome relationship API, it would be nice if an extension parsed out common relationships into something more useful.

For example, artists could be given members, originalMembers, and tributeArtists fields.

Not querying up to date data?

Running a search on both my Heroku deployed instance as well as GraphBrainz test instance results in out of date information.

For example searching for artist "Opeth" returns albums up to around the year 2002 when clearly MusicBrainz has all albums up to 2019.
Musicbranz site search: https://musicbrainz.org/artist/c14b4180-dc87-481e-b17a-64e4150f90f6

Searching on GraphBrainz test and my instance using the following which results in less data:
query OpethArtistInfo { lookup { artist(mbid: "c14b4180-dc87-481e-b17a-64e4150f90f6") { name mbid releases { edges { node { mbid title date } } } } } }

How do we go about retrieving actual up to date data? Is there something I am missing? @exogen

__typename-rels is not a valid inc parameter for the artist resource.

The below query

query Artist {
  node(id: "QXJ0aXN0OjMyM2VkOTc0LThiZjYtNGY1NC05NTI1LWI3NzRhNjU5ZjgwNQ==") {
    ... on Artist {
      relationships {
        __typename
      }
    }
  }
}

when used on https://graphbrainz.herokuapp.com/ fails with

{
  "errors": [
    {
      "message": "__typename-rels is not a valid inc parameter for the artist resource.",
      "locations": [
        {
          "line": 4,
          "column": 7
        }
      ],
      "path": [
        "node",
        "relationships"
      ]
    }
  ],
  "data": {
    "node": {
      "relationships": null
    }
  }
}

The problem seems to come from the __typename meta-field that is not correctly understood: https://spec.graphql.org/draft/#sec-Type-Name-Introspection

Is this project no longer going to be maintained?

Obviously there have been no commits to this repo in a long time but even cloning and deploying to Heroku no longer works as some dependencies in npmjs 404. If there is no plan to maintain the repo then shouldn't it be marked as such?

Support limit/offset alongside first/after?

I don't see any reason why limit & offset args couldn't be supported alongside first & after, to provide a more friendly schema for users who aren't using Relay. It might also just be confusing to have both.

An in-range update of standard is breaking the build 🚨

Version 10.0.1 of standard just got published.

Branch Build failing 🚨
Dependency standard
Current Version 10.0.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As standard is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • ci/circleci Your tests failed on CircleCI Details

  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • coverage/coveralls First build on greenkeeper/standard-10.0.1 at 99.334% Details

Commits

The new version differs by 12 commits .

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

An in-range update of express-graphql is breaking the build 🚨

Version 0.6.5 of express-graphql just got published.

Branch Build failing 🚨
Dependency express-graphql
Current Version 0.6.4
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

express-graphql is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Status Details
  • continuous-integration/travis-ci/push The Travis CI build is in progress Details,- ❌ ci/circleci Your tests failed on CircleCI Details

Commits

The new version differs by 96 commits0.

  • 78df509 0.6.5
  • 03605c2 Add compatibility with Restify (#272)
  • a03deae Silence lint warning
  • 16e1ed1 Capture and log errors internal to the app - not requests
  • cd3c661 Use supertest, supertest-as-promised was deprecated
  • e8594e2 Merge branch 'reapply'
  • e7a8001 Add compatibility with Restify (#272)
  • a0c1408 Use response.json when possible. Safer use of response.end.
  • 63ea52b Parse request params before options
  • 337142f Revert "Add favicon to prevent invalid GraphQL requests (#273)"
  • 1251757 Fix eslint deprecation warning
  • 8efe2dc Freshen yarn.lock
  • e180c8c Revert "Add compatibility with Restify (#272)"
  • 7110b54 Add favicon to prevent invalid GraphQL requests (#273)
  • c6fdf32 chore(package): update mocha to version 3.4.1

There are 96 commits in total.

See the full diff

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Rename artistCredit fields to artistCredits

Despite the key being artist-credit in the JSON returned from the REST API, the field is always referred to in the plural ("artist credits") elsewhere in the MusicBrainz documentation, it is a list of credits, and the inc parameter to include them is artist-credits.

Add artistCredits and add a deprecation notice for artistCredit.

An in-range update of graphql is breaking the build 🚨

Version 0.9.3 of graphql just got published.

Branch Build failing 🚨
Dependency graphql
Current Version 0.9.2
Type dependency

This version is covered by your current version range and after updating it in your project the build failed.

As graphql is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪


Status Details
  • ci/circleci Your tests passed on CircleCI! Details

  • continuous-integration/travis-ci/push The Travis CI build failed Details

Release Notes v0.9.3

Fixes

  • Eliminate false positives reported by findArgChanges (#783).
Commits

The new version differs by 47 commits .

  • 1407c05 0.9.3
  • b6b2a59 Freshen yarn.lock
  • 12d42a5 Merge pull request #802 from graphql/greenkeeper/babel-eslint-7.2.2
  • 0a56e28 Merge pull request #800 from joelgriffith/bugfix/find-breaking-arg-changes
  • 04b3cda chore(package): update babel-eslint to version 7.2.2
  • c52949d Tests to prevent this bug from happening again
  • 3277a1b Flow fixes
  • 28da1f0 Moving from raw instance check to name checks
  • 490dc49 Freshen yarn.lock
  • 8f06fda Merge pull request #795 from graphql/greenkeeper/babel-cli-6.24.1
  • d09f84c chore(package): update babel-cli to version 6.24.1
  • bb51c1a Freshen yarn.lock
  • 8dd926c Merge pull request #794 from graphql/greenkeeper/babel-plugin-transform-es2015-classes-6.24.1
  • 0a778ce chore(package): update babel-plugin-transform-es2015-classes to version 6.24.1
  • 4374027 Merge pull request #793 from graphql/greenkeeper/babel-plugin-transform-es2015-object-super-6.24.1

There are 47 commits in total. See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

An in-range update of ava is breaking the build 🚨

Version 0.19.1 of ava just got published.

Branch Build failing 🚨
Dependency ava
Current Version 0.19.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As ava is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • ci/circleci Your tests failed on CircleCI Details

  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • coverage/coveralls First build on greenkeeper/ava-0.19.1 at 99.334% Details

Release Notes 0.19.1

A bugfix release. See 0.19.0 for full release notes.

  • Prevent MaxListenersExceededWarning from being emitted if a test file contains more than 10 tests d27bc8f
  • Fix t.end() not being available in the TypeScript definition for callback tests bd81ef4
  • Fix t.context not being available in the Flow definition for beforeEach() and afterEach() hooks d169f0e
Commits

The new version differs by 5 commits .

  • 4cc3403 0.19.1
  • d169f0e Fix context for beforeEach and afterEach hooks in Flow type definition file (#1344)
  • bd81ef4 Fix TypeScript definition for callback tests
  • 6224f31 Set up regression testing for TypeScript
  • d27bc8f Avoid MaxListenersExceededWarning in Sequence

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Heroku app down

It seems like the Heroku demo is down; are there any plans for fixing it?

An in-range update of babel-register is breaking the build 🚨

Version 6.24.1 of babel-register just got published.

Branch Build failing 🚨
Dependency babel-register
Current Version 6.24.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-register is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • ci/circleci Your tests failed on CircleCI Details

  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • coverage/coveralls First build on greenkeeper/babel-register-6.24.1 at 99.334% Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Aliases and fragments can throw off resolvers

Since there are so many similar types and fields in the schema, the implementation for many of the resolvers is shared, and the appropriate handling is determined based on examining the requested fields in the query.

For example, in a query like { browse { releaseGroups(...) } }, we construct the API call to the release-group endpoint based on the fact that the field name is releaseGroups.

Aliases and fragments throw this off because we get the aliased/fragment names, not the ones we expect as defined in the schema. The information we need is there, it's just not being used properly at the moment.

An in-range update of babel-cli is breaking the build 🚨

Version 6.24.1 of babel-cli just got published.

Branch Build failing 🚨
Dependency babel-cli
Current Version 6.24.0
Type devDependency

This version is covered by your current version range and after updating it in your project the build failed.

As babel-cli is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪


Status Details
  • continuous-integration/travis-ci/push The Travis CI build passed Details

  • ci/circleci Your tests failed on CircleCI Details

  • coverage/coveralls First build on greenkeeper/babel-cli-6.24.1 at 99.334% Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.


Your Greenkeeper Bot 🌴

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.