dependency upgrades; graphql-tools bug fix, typescript 4.4, deprecated babel-eslint, clean up core/package.json

[thedavidprice]

Status:
Everything is working except for a type issue related to MSW cookies.

To Do:

• clean up core/package.json and remove x---x---x dependency (needed for Yarn v3 upgrade)
• swap out deprecated babel-eslint package
• magic sdk v5
  • Breaking re: "Custom session duration" (may affect custom implementations); See https://github.com/magiclabs/magic-js/blob/master/CHANGELOG.md and Custom session duration magiclabs/magic-js#199
• upgrade MSW v0.35
  • Release notes
  • need to address possible changes due to "Setting a Cookie/Set-Cookie response headers via ctx.set now produces a type violation (Rename project-model to structure. Install in CLI. #819). Please use ctx.cookie instead."
• TBD Firebase v9 (via PR Support email link authentication with Firebase #3347)
• add the error-overlay-plugin (now supporting Webpack v5) No go. Still buggy (see this)

babel-eslint is moved to @babel/eslint-parser

Overview:

• https://babeljs.io/blog/2020/07/13/the-state-of-babel-eslint

Migration:

• https://babeljs.io/blog/2020/07/13/the-state-of-babel-eslint

New parserOptions and adding path to Babel config:

• https://github.com/babel/babel/tree/main/eslint/babel-eslint-parser#additional-parser-configuration

Typescript Release Notes:

• https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-rc/

Breaking

https://devblogs.microsoft.com/typescript/announcing-typescript-4-4-rc/#use-unknown-catch-variables

Once TypeScript added the unknown type, it became clear that unknown was a better choice than any in catch clause variables for users who want the highest degree of correctness and type-safety, since it narrows better and forces us to test against arbitrary values.

catch(error) may now require catch(error: any)

ESBuild Release Notes:

• v0.12.27
  • Update JavaScript syntax feature compatibility tables
• v0.12.26
  • Add --analyze to print information about the bundle
  • Allow require.resolve in non-node builds

[dac09]

Did you see the breaking changes on graphql-tools @thedavidprice ?

[thedavidprice]

@dac09 I did but they didn't apply to us. However, my plan is to wait until #3307 is merged and then revisit.

Only breaking changes so far are TS 4.4 changing error type default to unknown from any (in case of catch(error)).

Lastly, I do want to make sure we try these out with Auth during QA. Might be the right time to add dbAuth to E2E/test-project, which it feels like we'll also need for GraphQL Directives, yes?

[thedavidprice]

cc @msutkowski

@dac09 I'm upgrading MSW in this PR and running into a TS build error:
https://github.com/redwoodjs/redwood/pull/3371/checks?check_run_id=3594852963#step:5:122

If you recall from a discussion awhile back, here's the source type issue:

redwood/packages/testing/src/web/mockRequests.ts

Line 123 in 1b554b0

set: captureTransform(ctx.set),

It is specifically on the ctx.set due to this breaking change in v0.33.0

Setting a Cookie/Set-Cookie response headers via ctx.set now produces a type violation (#819). Please use ctx.cookie instead.

I tried to diagnose as we first thought this might be due to overly strict typing restrictions. But then you thought the cause might actually be a bug with our typing of captureTransform (or maybe it was GraphQLContext). Any chance you could take a look at this branch and help diagnose?

[msutkowski]

cc @msutkowski

@dac09 I'm upgrading MSW in this PR and running into a TS build error:
https://github.com/redwoodjs/redwood/pull/3371/checks?check_run_id=3594852963#step:5:122

If you recall from a discussion awhile back, here's the source type issue:

redwood/packages/testing/src/web/mockRequests.ts

Line 123 in 1b554b0

set: captureTransform(ctx.set),

It is specifically on the ctx.set due to this breaking change in v0.33.0

Setting a Cookie/Set-Cookie response headers via ctx.set now produces a type violation (#819). Please use ctx.cookie instead.

I tried to diagnose as we first thought this might be due to overly strict typing restrictions. But then you thought the cause might actually be a bug with our typing of captureTransform (or maybe it was GraphQLContext). Any chance you could take a look at this branch and help diagnose?

Just do this: set: captureTransform(ctx.set as any),

I don't think there's a reason to try and fight with those types being that they're casted. If you try to do newCtx.set('cookie', 'banana') it'll give you the correct error.

Edit: also, sorry about the delay and radio silence! Hope ya'll are well :)

[thedavidprice]

Just do this: set: captureTransform(ctx.set as any),

Well, look at that... Done!

Edit: also, sorry about the delay and radio silence! Hope ya'll are well :)

All good! We're (slowly but surely) eyeing down the v1-rc, which is gonna be 🔥

Thanks as always for the help + support. Hope all's well on your end, too!

[thedavidprice]

@dac09 @dthyresson This one's ready to merge. Wanted you both to have a chance to see what's coming down the pipe...

[dac09]

Note sure about this one... mind walking me through what this does please?

[thedavidprice]

Sure thing, from the OP:

babel-eslint is moved to @babel/eslint-parser

Overview:

• https://babeljs.io/blog/2020/07/13/the-state-of-babel-eslint
  Migration:

• https://babeljs.io/blog/2020/07/13/the-state-of-babel-eslint
  New parserOptions and adding path to Babel config:

• https://github.com/babel/babel/tree/main/eslint/babel-eslint-parser#additional-parser-configuration

Parser now needs to know location of the babel.config.js or else it throws ('cause can't find otherwise in our directory structure). There's an option to ignore, but after reading docs that didn't seem correct for our case.

[thedavidprice]

Great catch @dac09 I'm now checking cwd and using findUp to get the babel.config, which works across Framework and Project now.

Also, I did confirm we must pass the babel config file to the parser. Breaks without it :-(

[dac09]

Do we need resolutions for ts-morph?

[thedavidprice]

Breaking here is ts-morph dependency upgrade to TS 4.4:
https://github.com/dsherret/ts-morph/blob/latest/packages/ts-morph/CHANGELOG.md#1200-2021-08-27

[thedavidprice]

@dac09 just updated babel-preset to get CORE_JS_VERSION from installed package = ✅

This is ready to go

[dthyresson]

@thedavidprice I fetched this PR and built, ran tests and ran e2e and all passed.

Apart from the error types question for @dac09 should be good to go.

But, CI has some Cypress issues -- cached node_modules (perhaps due to my committing a package change here vs another commit).

Can you reset this?

[thedavidprice]

@dthyresson Yeppers, that was the Cypress Cache error — first time I've seen it although DC says it shows up a lot on his PRs. Most likely resolved in the Yarn v3 PR (I changed the CI caching mechanism). Anyway, I gave it a kick and expect things to pass now.

@dac09 was there a question from DT about error types? Assuming he's talking about this type of change:
https://github.com/redwoodjs/redwood/pull/3371/files#diff-7bcac6982b532d462238a0e73d225686328dbba4357740a47b7d11c320729a02

I recall you saying that's the way to do it. Please confirm.

[dthyresson]

@dac09 was there a question from DT about error types?

@thedavidprice If you already went over this with Danny, then sounds good -- I was just curious about typing Errors.

Then approved and good to merge.