v17 Roadmap

[yaacovCR]

Some initial thoughts for PRs to consider for v17 are below. Please add comments for discussion! What would you like to see in v17?

Additional Type or Otherwise Breaking Changes:

• feat: allow symbols as GraphQLSchema extension fields #3511
• Replace 'find{Breaking,Dangerous}Changes' with generic 'findSchemaChanges' #2181

Multiple Packages/Bundling:

• instanceOf: disable dev instanceOf checks if NODE_ENV not set #4188
• implement bundling changes suggested in #4062 #4096
• fix(esm): added export mapping to package.json for proper cjs/esm entrypoints #4081
• fix(jsutils): use optional chaining to prevent crash in browser #4017
• suggestion: alternative check for multiple graphql packages #3915
• feat: replace instanceOf with unique Symbol checks #3617

Coercion/Validation:

• astFromValue - JavaScript BigInt support #4088
• Introduce astFromValueUntyped and handle object values within astFromValue correctly #4087
• RFC: Default value validation & coercion #3814
• Input Value Validation #3813
• Add valueToLiteral() #3812
• Preserve sources of variable values #3811

Possibly Already Fixed?

• getIntrospectionQuery should select kind for all types #3910

Meta-Docs:

• add draft for what's new in v17 #4198
• Upgrade Guides #3366

[jasonkuhrt]

Wonder if we could make the node types not read-only anymore? Wouldn't be a breaking change. Guessing there is a good reason for how it is now, but maybe not?

See #4212

[benjie]

Not sure if this is the best place for this, but here are some spec changes that I think we should aim to hit the V17 version; some of them are already merged:

• [RFC] Default value coercion rules graphql-spec#793
• Implementations may not deprecate a field that the interface hasn't deprecated graphql-spec#1053 / Reject deprecated fields when interface field is not deprecated #3986
• Add validation rule that operation types exist graphql-spec#955 / Mutation validates when schema does not support mutations #3592 / Add KnownOperationTypes rule #3601
• [RFC] Prevent @skip and @include on root subscription selection set graphql-spec#860 / Forbid @skip and @include directives in subscription root selection #3974
• Add explanation about argument name uniqueness. graphql-spec#891 / argument names are unique; I believe we use arrays to reference them in some places (e.g. field.args in type.toConfig()?) specifically because Ivan said the spec doesn't require they're unique. Now we do, we should use objects to make these things more ergonomic, like we use objects for fields (keyed by field name).
• Add 'extensions' to request graphql-spec#976 / I'm not sure if this actually needs anything to change in GraphQL.js TBH.

[JoviDeCroock]

use arrays to reference them in some places

Yes currently we allow for inputs to be done with the object syntax but we translate them to arrays in a lot of places. I think mainly to make introspection easier but that's not a great reason, we should change this.

graphql/graphql-spec#976 / I'm not sure if this actually needs anything to change in GraphQL.js TBH.

Unless this becomes part of the validate/execute phase we don't need any changes here.

[benjie]

Unless this becomes part of the validate/execute phase we don't need any changes here.

That was my initial thought too. Just looking around the codebase, I see ExecutionResult has extensions:

graphql-js/src/execution/execute.ts

Lines 127 to 134 in 6b253e7

	export interface ExecutionResult<
	TData = ObjMap<unknown>,
	TExtensions = ObjMap<unknown>,
	> {
	errors?: ReadonlyArray<GraphQLError>;
	data?: TData | null;
	extensions?: TExtensions;
	}

Perhaps GraphQLArgs should have this too:

graphql-js/src/graphql.ts

Lines 61 to 72 in b0f467d

	export interface GraphQLArgs {
	schema: GraphQLSchema;
	source: string | Source;
	hideSuggestions?: Maybe<boolean>;
	rootValue?: unknown;
	contextValue?: unknown;
	variableValues?: Maybe<{ readonly [variable: string]: unknown }>;
	operationName?: Maybe<string>;
	fieldResolver?: Maybe<GraphQLFieldResolver<any, any>>;
	typeResolver?: Maybe<GraphQLTypeResolver<any, any>>;
	abortSignal?: Maybe<AbortSignal>;
	}

And maybe even ExecutionArgs:

graphql-js/src/execution/execute.ts

Lines 145 to 155 in 6b253e7

	export interface ExecutionArgs {
	schema: GraphQLSchema;
	document: DocumentNode;
	rootValue?: unknown;
	contextValue?: unknown;
	variableValues?: Maybe<{ readonly [variable: string]: unknown }>;
	operationName?: Maybe<string>;
	fieldResolver?: Maybe<GraphQLFieldResolver<any, any>>;
	typeResolver?: Maybe<GraphQLTypeResolver<any, any>>;
	subscribeFieldResolver?: Maybe<GraphQLFieldResolver<any, any>>;
	}

This would be a type only change, but I imagine it allows for things like envelop to augment/read from extensions which may be useful. Maybe explicitly passing extensions from GraphQLArgs through to ExecutionArgs would be the one concrete (non-type) code change?