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

[PWA-1658] Move graphql-cli-validate-magento-pwa-queries to @magento scope #3198

Merged
merged 14 commits into from
Jun 8, 2021

Conversation

tjwiebell
Copy link
Contributor

@tjwiebell tjwiebell commented May 27, 2021

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 with graphql-cli-, so re-naming was not going to be possible. It seemed achievable that upgrading to graphql-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 get graphql 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

  1. yarn validate-queries - verify no errors returned (expected to see lots of deprecation warnings)
  2. yarn lint - verify no errors

Screenshots / Screen Captures (if appropriate)

Checklist

  • I have added tests to cover my changes, if necessary.
  • I have added translations for new strings, if necessary.
  • I have updated the documentation accordingly, if necessary.

@PWAStudioBot
Copy link
Contributor

PWAStudioBot commented May 27, 2021

Messages
📖

Associated JIRA tickets: PWA-1602.

📖 DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next nightly build run (assuming they are fixed).
📖

Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.

Generated by 🚫 dangerJS against 5b7fd9c

@tjwiebell tjwiebell force-pushed the tommy/rename-validator branch from 047411e to 063b1bc Compare May 27, 2021 18:19
gift_message
include_gift_receipt @client
include_printed_card @client
local_gift_message @client
Copy link
Contributor

Choose a reason for hiding this comment

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

Why the rename here?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@sirugh
Copy link
Contributor

sirugh commented Jun 1, 2021

Don't forget to provide the version label and, if breaking, to include in the PR description what breaks.

},
plugins: ['@graphql-eslint'],
rules: {
'@graphql-eslint/known-directives': 'error',
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'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.

@tjwiebell tjwiebell added the version: Major This changeset includes incompatible API changes and its release necessitates a Major version bump. label Jun 2, 2021
Copy link
Contributor

@sirugh sirugh left a 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'],
Copy link
Contributor

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.

Copy link
Contributor Author

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",
Copy link
Contributor

Choose a reason for hiding this comment

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

v3?

Copy link
Contributor Author

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

extensions: {
codegen: {
generates: {
'./merged-schema.v4.json': {
Copy link
Contributor

Choose a reason for hiding this comment

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

v4?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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",
Copy link
Contributor

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/

Copy link
Contributor Author

@tjwiebell tjwiebell Jun 3, 2021

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.

Copy link
Contributor Author

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

Copy link
Contributor

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).

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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):

  1. force a graphql resolution
  2. 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}",
  3. overcome default node_module exclusion by adding ignorePattern: '!node_modules/*' to linterConfiguration
    to node_modules/graphql-cli-validate-magento-pwa-queries/lib/index.js
  4. Profit? [bug]: Query uses non existing WishlistVisibilityEnum in CE #3217

Copy link
Contributor Author

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 {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

@dpatil-magento
Copy link
Contributor

QA Approved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants