Feedback on v16.0.0-rc.1

[IvanGoncharov]

Can you please test your lib/project against https://github.com/graphql/graphql-js/releases/tag/v16.0.0-rc.1 and leave feedback on this issue.

[kamilkisiela]

@apollo/federation:0.30.0 and previous versions

Cannot find module 'graphql/validation/rules/UniqueTypeNames'
at @apollo/federation/dist/composition/rules.js

[kamilkisiela]

Property 'isDeprecated' does not exist on type 'GraphQLField<any, any, { [argument: string]: any; }>'

Same story for Enums and other types.

[kamilkisiela]

ts(2724): '"graphql"' has no exported member named 'Visitor'. Did you mean 'visit'?

[kamilkisiela]

resolveType no longer accepts a type

  Type 'GraphQLObjectType<any, any>' is not assignable to type 'PromiseOrValue<string | undefined>'.
    Type 'GraphQLObjectType<any, any>' is not assignable to type 'string'.

I guess it previously was supported because of toString() and TS allowed for that, now it's not.

[PabloSzx]

Could collectFields be re-exported from /execution/execute.ts? this will help @graphql-tools/utils to not break with graphql 16, see:

• https://github.com/ardatan/graphql-tools/blob/master/packages/utils/src/visitResult.ts#L19

• 

EDIT: Created PR #3246

[PabloSzx]

Another thing, can a experimental-stream-defer version of this RC also be released?

[yaacovCR]

Could collectFields be re-exported from /execution/execute.ts? this will help @graphql-tools/utils to not break with graphql 16, see:

fixed/refactored on main #3187

Could be backported

[PabloSzx]

Could collectFields be re-exported from /execution/execute.ts? this will help @graphql-tools/utils to not break with graphql 16, see:

fixed/refactored on main #3187

Could be backported

#3246

[saihaj]

Another thing, can a experimental-stream-defer version of this RC also be released?

Yeah we need this @IvanGoncharov. I was looking into graphiql and there defer and stream is used

[saihaj]

express-graphql

Updating works fine all the tests pass. Only issue is that there peer deps conflicts which requires updating graphiql and subscriptions-transport-ws so once a new version for them is released we can update it

graphql-relay-js

There are expected breaking changes that require some changes. Since we no longer export flow types so we should do this upgrade part of TS migration.

[n1ru4l]

Breaks 'apollo-server-core':

const apolloServer = new ApolloServerBase({ schema, debug });

yields in the exception

      Must provide document.

      at devAssert (node_modules/graphql/jsutils/devAssert.js:12:11)
      at assertValidExecutionArguments (node_modules/graphql/execution/execute.js:145:40)
      at Object.execute (node_modules/graphql/execution/execute.js:74:3)
      at Object.generateSchemaHash (node_modules/apollo-server-core/src/utils/schemaHash.ts:12:18)
      at ApolloServerBase.generateSchemaDerivedData (node_modules/apollo-server-core/src/ApolloServer.ts:671:24)
      at Object.schemaDerivedDataProvider (node_modules/apollo-server-core/src/ApolloServer.ts:288:18)
      at new SchemaManager (node_modules/apollo-server-core/src/utils/schemaManager.ts:75:15)
      at new ApolloServerBase (node_modules/apollo-server-core/src/ApolloServer.ts:283:24)

Seems like apollo-server is using the legacy execute call signature execute(schema, ...args) instead of execute({ schema, ...args })

[n1ru4l]

Previously the mapAsyncIterator function could be imported via

import mapAsyncIterator from 'graphql/subscription/mapAsyncIterator.js';

but the export was changed to import { mapAsyncIterator } from 'graphql/subscription/mapAsyncIterator.js';

Could we still have a default export for having easy backward compatibility without having to inline the function into our libraries?

I created #3247 for this simple change

[n1ru4l]

Parser class attributes are private and should be protected instead for implementing custom parsers. #3248

[n1ru4l]

GraphQLError now has this:

https://github.com/n1ru4l/graphql-js/blob/4493ca3d1281e01635570824f70867aa68610323/src/error/GraphQLError.ts#L204-L207

But the comment indicates it should be removed? SHould this be removed or is the comment outdated? This also causes TS errors for apollo-server.