graphql@0.9.0 breaks build 🚨

[greenkeeperio-bot]

Hello lovely humans,

graphql just published its new version 0.9.0.

State	Failing tests 🚨
Dependency	graphql
New version	0.9.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build went from success to failure.

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 💪

Of course this could just be a false positive, caused by a flaky test suite, or third parties that are currently broken or unavailable, but that would be another problem I’d recommend working on.

Do you have any ideas how I could improve these pull requests? Did I report anything you think isn’t right?
Are you unsure about how things are supposed to work?

There is a collection of frequently asked questions and while I’m just a bot, there is a group of people who are happy to teach me new things. Let them know.

Good luck with your project ✨

You rock!

🌴

---

GitHub Release

New:

Added isNamedType() and assertNamedType() #589
Default field resolvers now get full execution info as a third argument #615
ObjectType.isTypeOf() and InterfaceType.resolveType() may now return Promises #631
Support and fixes for flow type v0.38 #671
Added TypeInfo.getEnumValue() and EnumType.getValue(name) #674
Added findDeprecatedUsages() #676

Fixes:

Enforce spec that no non-meta field may start with "__" #600 (Potentially breaking for existing non-compliant uses).
isValidJSValue() reports if coercion results in error #602
Executor throws friendlier error if no document is provided #614
Fixed import circular dependency, improving compressed builds #644

---

The new version differs by 292 commits .

• 43cd3bb 0.9.0
• e7b4bc7 Update dependencies
• 5b26da9 Improve type definitions
• 15d2184 Merge pull request #631 from dherault/master
• 0417aad Simplify default resolver function
• a3c746c Factor out checking isTypeOf from subfield exe
• 9239253 Pass lint & flow
• c53efbe Missing comma
• b40d427 Fix completeObjectValue call bug
• 1fb45d3 Factor out runtime type validation
• 1305360 Reduce scope
• 7064b9d Merge pull request #675 from robzhu/master
• d1f586e Merge pull request #676 from graphql/find-deprecated
• 3a53f25 Freshen yarn.lock
• d7d6110 Merge pull request #686 from graphql/greenkeeper/babel-cli-6.22.2

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

---

✨ Try the all new Greenkeeper GitHub Integration ✨
With Integrations first-class bot support landed on GitHub and we’ve rewritten Greenkeeper to take full advantage of it. Simpler setup, fewer pull-requests, faster than ever. Screencast Try it today. Free for private repositories during beta.

[calebmer]

Oh boy. This is annoying.

As a side effect of trying to get __id into the spec what actually ended up happening was that PR got closed graphql/graphql-spec#232, and then this PR got merged graphql/graphql-spec#244. So to enforce the addition this was merged into GraphQL-js graphql/graphql-js#600.

In short, we can’t use __id and have to find a different name. How about _id? 😉

[benjie]

I'm partial to _id_ as it's extremely unlikely to be used elsewhere. _id would work for me also, but I think the risk of clashes is higher. We could go more explicit with gqlid or postgraphqlId or similar. Perhaps nodeId would be okay, given node is a generic interface and if you have a model called Node you're kind of screwed already.

Okay; having thought about it a bit, I'm thinking nodeId or _nodeId are good compromises, I'm erring towards the latter to avoid collisions just in case.

(Ugh, this is going to make so much work.)

[calebmer]

I like nodeId, but yeah I agree on the work bit 😖

I definitely disagree with this decision by Facebook, but I understand the motivation. Implementing the error in GraphQL-js felt a bit overkill to me, though.

[benjie]

I created a wiki page a while ago about reserved words: https://github.com/calebmer/postgraphql/wiki/Reserved-Keywords-Tablenames

Since node/nodes are already reserved, I think node_id/nodeId would be natural additions.

[calebmer]

Ok, closing this issue and I’ll open up another one with a solution.