fix(internals-js): recognize @oneOf as a built-in directive - #3467
Open
DevRichter wants to merge 2 commits into
Open
fix(internals-js): recognize @oneOf as a built-in directive#3467DevRichter wants to merge 2 commits into
DevRichter wants to merge 2 commits into
Conversation
|
@DevRichter: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Apollo Contributor License Agreement here: https://contribute.apollographql.com/ |
🦋 Changeset detectedLatest commit: 36cee05 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
✅ AI Style Review — No Changes DetectedNo MDX files were changed in this pull request. Review Log: View detailed log
|
@OneOf has been part of the GraphQL spec since graphql-js 16.9, but internals-js's built-in directive whitelist was never updated for it, so any subgraph SDL using @OneOf on an input type failed with "Unknown directive" in both buildSubgraphSchema and composeServices. Also bumps the repo's dev-only graphql pin from 16.8.1 to 16.9.0, the minimum version where @oneOf/isOneOf are implemented in graphql-js, since Schema#toGraphQLJSSchema builds the final schema via graphql-js's own buildASTSchema and needs that support for this fix to take effect. Fixes apollographql#3437
DevRichter
force-pushed
the
fix/oneof-builtin-directive
branch
from
August 5, 2026 15:17
fe81dc7 to
635d6c1
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
oneOftographQLBuiltInDirectivesSpecificationsininternals-js/src/definitions.tsso it's recognized as a built-in directive, the same waydeprecated/specifiedBy/defer/streamalready are. Also bumps the repo's dev-onlygraphqlpin from16.8.1to16.9.0.Why
Fixes #3437.
@oneOfhas been part of the GraphQL spec since graphql-js 16.9, butinternals-js's built-in directive whitelist was never updated for it. As a result, any subgraph SDL using@oneOfon an input type fails with "Unknown directive" — both when building/printing a single subgraph schema and when composing multiple subgraphs, since@apollo/subgraphand@apollo/compositionshare this validation.The
graphqlversion bump is required for the fix to actually take effect (and to be testable in this repo):Schema#toGraphQLJSSchemabuilds the final schema via graphql-js's ownbuildASTSchema, and@oneOf/isOneOfaren't implemented in graphql-js until 16.9.0 — 16.8.1 (the repo's current pin) rejects@oneOfoutright, independent of this fix.16.9.0is the minimum needed, chosen over jumping to latest to keep the change scoped.How
INPUT_OBJECTlocation, no arguments — matches the directive's definition in the GraphQL spec and in graphql-js's ownspecifiedDirectives.GraphQLInputObjectType.isOneOf = trueon the resulting graphql-js schema, so this isn't just a printing fix — runtime "exactly one field" enforcement works too.definitions.test.tscovering the input-object case (mirroring the existing@specifiedByscalar test in the same describe block) and an integration test insubgraphValidation.test.tscovering thebuildSubgraph/printSchemaround trip that@apollo/subgraphand@apollo/compositionrely on.