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

Create --variant flag, deprecate --tag flag #1849

Merged
merged 21 commits into from
Mar 25, 2020

Conversation

zionts
Copy link
Contributor

@zionts zionts commented Mar 25, 2020

This PR changes all commands that previously used a --tag flag to additionally include a --variant (alias -v) flag that can be used instead. These two different flags are exclusive, so no command can pass both a --tag and a --variant. The PR may look daunting at a glance, but please go commit-by-commit to see the progression, and I hope that will make it really manageable! These changes were QA'ed manually, and all tests were updated and inspected to ensure that they continued to work as expected. Some other small changes were added, which are noted in commit messages.

This is rebased off of #1847 , so check that one out first :)
See apollographql/apollo#819 for the corresponding documentation update 🎉

Notably, they include:

  • Changing messages in service:check to include @variant where appropriate
  • Changing (buggy) logic in several places that were using flags.tag directly rather than config.tag, in GraphQL commands. This could have caused issues for people that were not using a --tag flag but instead were using service { name: 'blah@foo' }, in that their command would fail unexpectedly.

Error message when both --tag and --variant are set:
image

client:push with --tag (note deprecation warning):
image

client:push with --variant:
image

client:check with --tag:
image

client:check with --variant:
image

client:codegen with --tag:
image

client:codegen with --variant:
image

service:push (federated) with --tag:
image

service:push (un-federated) with --variant:
image

service:check (un-federated) with --tag:
image

service:check (federated) with --variant:
image

service:list with --tag:
image

service:list with --variant:
image

service:list with neither --tag nor --variant, just to show that defaults work :)
image

Also throwback to #1398 🎉 Credit to former me & @jgzuke for inspiration, along with whomever made the config magic (which I think may have been @trevor-scheer?), which I relied on heavily here :)

TODO:

  • Update CHANGELOG.md* with your change (include reference to issue & this PR)
  • Make sure all of the significant new logic is covered by tests
  • Rebase your changes on master so that they can be merged easily
  • Make sure all tests and linter rules pass

*Make sure changelog entries note which project(s) has been affected. See older entries for examples on what this looks like.

@zionts zionts changed the base branch from master to adam/20/3/no-graph-found-error March 25, 2020 05:17
@zionts zionts requested a review from JakeDawkins March 25, 2020 05:43
@@ -162,12 +162,12 @@ export class ApolloConfig {
return configs;
}

set tag(tag: string) {
this._tag = tag;
set variant(tag: string) {
Copy link
Contributor

Choose a reason for hiding this comment

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

My only concern is if this breaks anything in vs code. But I don’t think it should

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I admit I didn't test with VS code, but mainly because I don't know how to test a local build! Is there a QA practice we go through before release?

Copy link
Contributor

Choose a reason for hiding this comment

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

Not in a consistent way! I’ll run through all this before releasing, but I don’t expect any issue here since it only interfaces with the language server anyway :)

@@ -3,7 +3,14 @@
## Upcoming

- `apollo`
- <First `apollo` related entry goes here>
- https://github.com/apollographql/apollo-tooling/pull/1849
Copy link
Contributor

Choose a reason for hiding this comment

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

Formatting of this entry isn’t consistent with what we have but I’m not concerned too much there, and that’s non blocking. I can amend before releasing since I’ll have to do that anyway

Adam Zionts added 21 commits March 25, 2020 11:19
These default flags were still referencing Apollo Engine instead of
Graph Manager (even though some were hidden). Additionally, this updates
the docs to be more accurate. Happy to take this commit into another PR
if you'd like!
This change supports the variant flag (with character -v) in addition to
the "tag" flag, which allows us to start using the new terminology. The
'--tag' flag is still supported, and there is verification that the two
sibling flags cannot be used together.
Also remove an unused variable in service:list
Also update description of the flags
Also simplify an import in apollo-language-server
Also add a XXX comment to service:download to illustrate a problem
Additionally, this updates the text output in the service:check command
to consistently use graph@variant everywhere
This is a find and replace all, and I verified every command still works
after this (both with --tag and --variant). Will post screenshots of how
everything looks in the PR :)
A previous commit added `@variant` everywhere, and these snapshot
updates should be ONLY that.
All of the client commands share common flags, so no further changes are
required. Also, all of them use config.variant, so yay! :)
Remove the deprecation warning from specific callsites and rely on the
deprecation warning appearing when the config.variant value is set
Also, this changes the default value of the flag, but it does NOT change
the behaviour, since `config.variant` always defaults to "current" if
flags and configuration are not set. The reason this was done is because
flags.tag will be non-null if there is a default, which causes the
deprecation message to always print
Mainly renaming service to graph and "schema" to service, which felt a
little meh, but more in line with the name of the command
This should only include changes to some minor message changes in
service:check
@zionts zionts force-pushed the adam/20/3/rename-tag-to-variant branch from 2497248 to 85e49e9 Compare March 25, 2020 18:19
@zionts zionts changed the base branch from adam/20/3/no-graph-found-error to master March 25, 2020 18:21
@JakeDawkins JakeDawkins merged commit 04bf842 into master Mar 25, 2020
@JakeDawkins JakeDawkins deleted the adam/20/3/rename-tag-to-variant branch March 25, 2020 18:35
zionts pushed a commit that referenced this pull request Mar 27, 2020
This supports a more modern name for the API key and adds deprecation
messages for the (now legacy) ENGINE_API_KEY. Much in the same spirit
as #1849, the goal
is to modernize our documentation to no longer use the out-of-date name
"engine". This also modifies tests to support the new version and adds a
test that ensures an error is thrown when a user sets _both_ keys.
JakeDawkins pushed a commit that referenced this pull request Mar 30, 2020
* Support APOLLO_KEY, deprecate ENGINE_API_KEY

This supports a more modern name for the API key and adds deprecation
messages for the (now legacy) ENGINE_API_KEY. Much in the same spirit
as #1849, the goal
is to modernize our documentation to no longer use the out-of-date name
"engine". This also modifies tests to support the new version and adds a
test that ensures an error is thrown when a user sets _both_ keys.
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.

None yet

2 participants