-
Notifications
You must be signed in to change notification settings - Fork 685
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
[PWA-1658] Move graphql-cli-validate-magento-pwa-queries to @magento scope #3198
Conversation
|
047411e
to
063b1bc
Compare
gift_message | ||
include_gift_receipt @client | ||
include_printed_card @client | ||
local_gift_message @client |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the rename here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gift_message
is a field in Cart
now, which didn't have the same type as our local defined one; validator threw an error. I don't think it did at the time of writing, so this ideally this should be re-factored to use the real fields, now that they're available. Could be a good first task for community, happy to write that up if you agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea I think the original intent behind the message was to actually hook this up :) As is, it doesn't actually do anything which might be surprising.
Don't forget to provide the version label and, if breaking, to include in the PR description what breaks. |
- Update scaffold template to remove old commands
}, | ||
plugins: ['@graphql-eslint'], | ||
rules: { | ||
'@graphql-eslint/known-directives': 'error', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only added a small subset of rules here from packages/graphql-cli-validate-magento-pwa-queries/lib/index.js
. When I added all the validation rules listed in that file, the linter blew up with errors, so I suspect those validation rules weren't working as expected. Trying to keep this scope minimal to just feature parity with what we had before, which I why I selected this subset of rules that were working.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work, only a few comments. And I'm getting some failures locally around wishlistFragment (of which you are aware).
.eslintrc.js
Outdated
}, | ||
overrides: [ | ||
{ | ||
files: ['**/*.gql.js'], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have some files named *.gql.ce.js
and .gql.ee.js
which I believe will get missed by this rule.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated pattern in b9de346
@@ -1,25 +1,11 @@ | |||
{ | |||
"projects": { | |||
"venia": { | |||
"schemaPath": "lastCachedGraphQLSchema.json", | |||
"schemaPath": "merged-schema.v3.json", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
v3
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Config structure for graphql-config@3
graphql.config.js
Outdated
extensions: { | ||
codegen: { | ||
generates: { | ||
'./merged-schema.v4.json': { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
v4
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New config structure for graphql-config@4
. This codegen is actually broken until we fix a lot of other naming collisions, so I may remove this until we can resolve those.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed codegen section in 52ed88d
@@ -0,0 +1,19 @@ | |||
extend type Query { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mind throwing a comment block above explaining who/what this file is for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For sure 👍 intend to collocate these closer to where they are defined, similar to what I did with the checkmo extension.
"lint": "eslint --ignore-path .gitignore 'src/**/{*.js,package.json}'", | ||
"prettier": "prettier --loglevel warn --ignore-path .gitignore 'src/**/*.@(css|graphql|js)' '*.js'", | ||
"prettier:check": "yarn run -s prettier -- --check", | ||
"prettier:fix": "yarn run -s prettier -- --write", | ||
"start": "buildpack serve .", | ||
"start:debug": "node --inspect-brk ./node_modules/.bin/webpack-dev-server --progress --color --env.mode development", | ||
"test": "yarn run -s prettier:check && yarn run -s lint && jest", | ||
"validate-queries": "yarn run download-schema && graphql validate-magento-pwa-queries --project venia", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yarn build:dev
uses this command still - will removing it cause breaks?
Also how will folks validate their queries in their scaffolded apps without this script/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the fileglob that was previously in .graphqlconfig
that was used by the plugin. validate-queries
didn't actually do anything in scaffolded apps 😬 those packages would be in node_modules on a scaffold. The feature parity I was aiming for was just to restore validation in the monorepo.
"filesGlob": "../{peregrine,venia-ui,venia-concept}/{lib,src}/**/*.{js,graphql,gql}"
edit - But yes, this would cause breakage in build:dev
. Will remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed from build:dev
in b9de346
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
validate-queries didn't actually do anything in scaffolded apps
I am not 100% sure that validate-queries
is not doing nothing on scaffolded apps. You can test this by pointing your MAGENTO_BACKEND_URL at an invalid server. If you then run yarn watch prior to this PR you will get something like
message: 'invalid json response body at https://magento2.foomanstore.test/graphql reason: Unexpected token p in JSON at position 4',
type: 'invalid-json'
So while we may not validate any queries at least grapqhl schema needs to generate successfully (funnily we have had a case where the back-end schema did not work but all other queries did).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fooman - This was a tiny reason why I left the graphql-config@2
or .graphqlconfig
around in venia-concept
, but for a different reason; so IDEs would still be able to fetch schemas to provide in editor validation (eg. I use this webstorm plugin, which doesn't yet support v3).
Ideal state is that validation works in scaffolded apps the same as the monorepo, and the state in this PR is no validation. We do introspection at build time for fragment matching, so I'm not sure a validate-queries
command would indicate much, but happy to hear any ideas for a middle ground state that isn't just a removal of this command. Is this more about the nice messaging the previous plugin provided?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for getting back to me. Can confirm that latest scaffolded is not working well with validate-queries
(it may have done so in the past as did see a lastCachedGraphQLSchema.json
at some point). So I guess the suggestion here is reasonable to fix it first for the monorepo and then hopefully we can get this to work with scaffolded apps as the next step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With quite a bit of tinkering I am now able to run validate-queries locally in a scaffolded apps.
In rough steps (I am not running the same apollo version which may be the reason for step 1):
- force a graphql resolution
- edit .graphqlconfig to find the files under node_modules with
"filesGlob": "./node_modules/@magento/{peregrine,venia-ui,venia-concept}/{lib,src}/**/*.{graphql,gql,gql.js}",
- overcome default node_module exclusion by adding
ignorePattern: '!node_modules/*'
to linterConfiguration
to node_modules/graphql-cli-validate-magento-pwa-queries/lib/index.js - Profit? [bug]: Query uses non existing WishlistVisibilityEnum in CE #3217
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@fooman
Given how tech debt is usually treated I'll see if I can make that happen in this scope. PR welcome, otherwise I'll work on it tomorrow.
export const GET_PAYMENT_NONCE = gql` | ||
query getPaymentNonce($cartId: String!) { | ||
cart(cart_id: $cartId) @client { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In many of the queries we move @client
to the local such as here for paymentNonce
. Does this result in many more queries than were previously sent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the fetchPolicy was cache-and-network
, I could maybe see this hitting the network now. I was getting a validation error with these on the operation instead of the fields, but now that those directives are merged into the schema, I'm not getting those anymore. I think this can safely be backed out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted these directive changes in b9de346
QA Approved |
Description
As part of https://jira.corp.magento.com/browse/PWA-1602 we realized that all our packages except graphql-cli-validate-magento-pwa-queries are under the @magento custom scope.
Using custom scopes safe guards us against supply chain attacks. So as part of this PR, lets move graphql-cli-validate-magento-pwa-queries under magento scope and deprecate the old package.
Acceptance Criteria
Publish the package to the new namespace / scope
Submit a PR pointing any existing code in PWA Studio to the new package, to be released in the next PWA Studio release
Communicate the upcoming deprecation to stakeholders, including community
(Ideally after next release) post a deprecation notice / deprecate the existing package that is not in the magento scope
Proposed Solution
graphql-cli@3
requires plugin names begin withgraphql-cli-
, so re-naming was not going to be possible. It seemed achievable that upgrading tographql-cli@4
would mean we could leverage their new plugin framework, but from my discovery the naming requirement now meant you had to be in the@graphql-cli
namespace. Before digging too much into that solution, I instead focused on what it would take to getgraphql validate
working in the project.The solution proposed has some flaws, and is a tiny bit less feature rich, but accomplishes the same task. It also gives us the opportunity to start leveraging some cooler features of
graphql-cli
, like type generation, or change how we approach operation creation.Related Issue
Related PRs
Acceptance
Verification Stakeholders
Specification
Verification Steps
yarn validate-queries
- verify no errors returned (expected to see lots of deprecation warnings)yarn lint
- verify no errorsScreenshots / Screen Captures (if appropriate)
Checklist