Update usage of registerOperations for v2 operations manifest#1118
Merged
abernix merged 1 commit intorelease-apollo-3.xfrom Mar 15, 2019
Merged
Update usage of registerOperations for v2 operations manifest#1118abernix merged 1 commit intorelease-apollo-3.xfrom
abernix merged 1 commit intorelease-apollo-3.xfrom
Conversation
trevor-scheer
force-pushed
the
trevor/update-registerOperations-usage
branch
from
5ee175f to
c547a09
Compare
abernix
reviewed
Mar 15, 2019
Member
abernix
left a comment
abernix
left a comment
There was a problem hiding this comment.
Possibly suggestion of using manifestVersion, for discussion, otherwise looks great!
trevor-scheer
force-pushed
the
trevor/update-registerOperations-usage
branch
from
c547a09 to
ffe1f65
Compare
Now that registerOperations supports version as an argument to the mutation, we can leverage this for v2 oeprations manifest work.
trevor-scheer
force-pushed
the
trevor/update-registerOperations-usage
branch
from
ffe1f65 to
ef5b10a
Compare
abernix
approved these changes
Mar 15, 2019
abernix
approved these changes
Mar 15, 2019
abernix
pushed a commit
that referenced
this pull request
Apr 2, 2019
This includes the work from #1027, #1115 and #1118, which first surfaced in an `apollo@next` CLI version which was released in order to provide a migration path for paying customers who utilize the Apollo Operation Registry through the CLI's `apollo client:push` features. Those customers were notified and advised to either pin their `apollo` version prior to this being released, so the hope is that we'll be able to released this under the `apollo@2` cover without incurring breaking changes on anyone else. The summary of the relevant commit messages is below: 1) Remove duplication from client:push and client:extract. 2) Create a test to verify upcoming changes for this PR. Cutover to apollo-graphql * Add apollo-graphql as a dependency (and project reference) * Remove apollo-engine-reporting as a dependency * Update sortAST to normalize order of fragments w.r.t operations * Tests are failing expectedly at this point Centralize operation hashing function These two operations will likely be used in tandem, and we want this to be consistent across consumers. Incorporate rename suggestions Update version for extracted manifest output. Use empty string and add comment about unused metadata field. Revert changes to defaultEngineReportingSignature. Apply changes to new function, defaultOperationRegistrySignature. This new function is the effective interim fix, and the current existing function is now left alone. Pass operation name along to the operation registry signature function Leverage updated registerOperations API Now that registerOperations supports version as an argument to the mutation, we can leverage this for v2 oeprations manifest work.
abernix
pushed a commit
that referenced
this pull request
Apr 2, 2019
This includes the work from #1027, #1115 and #1118, which first surfaced in an `apollo@next` CLI version which was released in order to provide a migration path for paying customers who utilize the Apollo Operation Registry through the CLI's `apollo client:push` features. Those customers were notified and advised to either pin their `apollo` version prior to this being released, so the hope is that we'll be able to released this under the `apollo@2` cover without incurring breaking changes on anyone else. The summary of the relevant commit messages is below: 1) Remove duplication from client:push and client:extract. 2) Create a test to verify upcoming changes for this PR. Cutover to apollo-graphql * Add apollo-graphql as a dependency (and project reference) * Remove apollo-engine-reporting as a dependency * Update sortAST to normalize order of fragments w.r.t operations * Tests are failing expectedly at this point Centralize operation hashing function These two operations will likely be used in tandem, and we want this to be consistent across consumers. Incorporate rename suggestions Update version for extracted manifest output. Use empty string and add comment about unused metadata field. Revert changes to defaultEngineReportingSignature. Apply changes to new function, defaultOperationRegistrySignature. This new function is the effective interim fix, and the current existing function is now left alone. Pass operation name along to the operation registry signature function Leverage updated registerOperations API Now that registerOperations supports version as an argument to the mutation, we can leverage this for v2 oeprations manifest work.
abernix
pushed a commit
that referenced
this pull request
Apr 2, 2019
This includes the work from #1027, #1115 and #1118, which first surfaced in an `apollo@next` CLI version which was released in order to provide a migration path for paying customers who utilize the Apollo Operation Registry through the CLI's `apollo client:push` features. Those customers were notified and advised to either pin their `apollo` version prior to this being released, so the hope is that we'll be able to released this under the `apollo@2` cover without incurring breaking changes on anyone else. For more information on the operation registry, see: https://www.apollographql.com/docs/platform/operation-registry.html And if you encounter any problems, please contact our customer support via Intercom from within your Engine UI. --- The summary of the relevant commit messages is below: 1) Remove duplication from client:push and client:extract. 2) Create a test to verify upcoming changes for this PR. Cutover to apollo-graphql * Add apollo-graphql as a dependency (and project reference) * Remove apollo-engine-reporting as a dependency * Update sortAST to normalize order of fragments w.r.t operations * Tests are failing expectedly at this point Centralize operation hashing function These two operations will likely be used in tandem, and we want this to be consistent across consumers. Incorporate rename suggestions Update version for extracted manifest output. Use empty string and add comment about unused metadata field. Revert changes to defaultEngineReportingSignature. Apply changes to new function, defaultOperationRegistrySignature. This new function is the effective interim fix, and the current existing function is now left alone. Pass operation name along to the operation registry signature function Leverage updated registerOperations API Now that registerOperations supports version as an argument to the mutation, we can leverage this for v2 oeprations manifest work.
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
2 participants
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.
Now that registerOperations supports version # as an argument to the mutation, we can leverage this for v2 operations manifest work.
This PR finalizes the CLI work to wrap up the sorting fragments bug that lives in v1 of the manifest (currently, the current version of the manifest, but soon to be the previous version).
TODO: