Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update usage of registerOperations for v2 operations manifest #1118

Merged
merged 1 commit into from
Mar 15, 2019

Conversation

trevor-scheer
Copy link
Member

@trevor-scheer trevor-scheer commented Mar 14, 2019

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:

  • Verify both codegen type check and query check pass after ^
  • Upon landing, publish updated alpha release

@trevor-scheer trevor-scheer force-pushed the trevor/update-registerOperations-usage branch from 5ee175f to c547a09 Compare March 14, 2019 23:48
Copy link
Member

@abernix abernix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly suggestion of using manifestVersion, for discussion, otherwise looks great!

@trevor-scheer trevor-scheer force-pushed the trevor/update-registerOperations-usage branch from c547a09 to ffe1f65 Compare March 15, 2019 12:52
Now that registerOperations supports version as an argument
to the mutation, we can leverage this for v2 oeprations manifest
work.
@trevor-scheer trevor-scheer force-pushed the trevor/update-registerOperations-usage branch from ffe1f65 to ef5b10a Compare March 15, 2019 12:54
@abernix abernix merged commit 3546adc into release-apollo-3.x Mar 15, 2019
@abernix abernix deleted the trevor/update-registerOperations-usage branch March 15, 2019 17:32
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants