fix: support typescript 5.1 as a peer dependency

[gthb]

Loosen peer dependency constraint to unblock projects that use msw from upgrading to TypeScript 5.1.x.

Closes #1631

Also bump Typescript-related dev dependencies @typescript-eslint/eslint-plugin and @typescript-eslint/parser to current minor versions.

Some of the above required bumping tsup to 6.7.0 in which that project likewise loosened its peer dependency version constraint, from ^4.1.0 to >=4.1.0.

[gthb]

Huh, codesandbox CI fails with:

+ pnpm -v (in /tmp/7e27e2ea)
7.26.3
+ pnpm install (in /tmp/7e27e2ea)
 WARN  Your pnpm-lock.yaml was generated by a newer version of pnpm. It is a compatible version but it might get downgraded to version 6.0
Lockfile is up to date, resolution step is skipped
 ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  Broken lockfile: no entry for '/@mswjs/cookies/0.2.2' in pnpm-lock.yaml

This issue is probably caused by a badly resolved merge conflict.
To fix the lockfile, run 'pnpm install --no-frozen-lockfile'.
{ Error: Process rejected with status code 1
    at ChildProcess.<anonymous> (/app/dist/utils/exec.js:20:27)
    at ChildProcess.emit (events.js:198:13)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12) code: 1 }

... but the lock file does have entries for that package:

❯ rg -C1  @mswjs/cookies pnpm-lock.yaml
10-dependencies:
11:  '@mswjs/cookies':
12-    specifier: ^0.2.2
--
2371-
2372:  /@mswjs/cookies@0.2.2:
2373-    resolution: {integrity: sha512-mlN83YSrcFgk7Dm1Mys40DLssI1KdJji2CMKN8eOlBqsTADYzj2+jWzsANsUTFbxDMWPD5e9bfA1RGqBpS3O1g==}

and the suggested command pnpm install --no-frozen-lockfile changes nothing.

EDIT: redoing the pnpm install with pnpm 7.26.3 seems to have gotten past this. So this was probably something to do with that warning about the lock-file version.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 888cc8d:

Sandbox	Source
MSW React	Configuration

[kettanaito]

Hi, @gthb. This looks great.

One thing to add, we also need to add an automated type check test for TS 5.1 You can find existing tests in here. Then adding a new version to the TS versions matrix should do it, I believe.

Would you be interested in adding those, please?

[merajshaikh]

thanks for taking care of this @gthb @kettanaito

[urakymzhan]

Any updates on when this PR will be merged? I am facing peerdep issue with typescript 5.1.3 @types/react 18.2.8

[gthb]

@kettanaito Is that segmentation fault problem at all familiar to you? In CI:

 FAIL test/node/msw-api/setup-server/scenarios/response-patching..node.test.ts
  ● returns a combination of mocked and original responses

    FetchError: request to https://test.mswjs.io/user failed, reason: You need to run with a version of node that supports ES Modules in the VM API. See https://jestjs.io/docs/ecmascript-modules

      at NodeClientRequest.<anonymous> (../../node_modules/.pnpm/node-fetch@2.6.9/node_modules/node-fetch/lib/index.js:1505:11)
      at NodeClientRequest.Object.<anonymous>.NodeClientRequest.emit (../../node_modules/.pnpm/@mswjs+interceptors@0.17.7/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:299:22)
      at ../../node_modules/.pnpm/@mswjs+interceptors@0.17.7/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:153:14

  ● bypasses a mocked request when using "ctx.fetch"

    FetchError: request to https://test.mswjs.io/complex-request?bypass=true failed, reason: You need to run with a version of node that supports ES Modules in the VM API. See https://jestjs.io/docs/ecmascript-modules

      at NodeClientRequest.<anonymous> (../../node_modules/.pnpm/node-fetch@2.6.9/node_modules/node-fetch/lib/index.js:1505:11)
      at NodeClientRequest.Object.<anonymous>.NodeClientRequest.emit (../../node_modules/.pnpm/@mswjs+interceptors@0.17.7/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:299:22)
      at ../../node_modules/.pnpm/@mswjs+interceptors@0.17.7/node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/NodeClientRequest.ts:153:14

/Users/runner/work/_temp/f35c4e6b-edbd-4bdd-bdaf-8972dbae668b.sh: line 1:  2695 Segmentation fault: 11  pnpm test:node
Error: Process completed with exit code 139.

and when I run locally (Node.js v16.18.0, also on macOS) I get a DeprecationWarning, and then the same segmentation fault but not preceded by the two failures in that test module:

❯ pnpm test:node

> msw@1.2.1 test:node /Users/gthb/git/msw
> jest --config=./test/jest.config.js

 FAIL  test/node/msw-api/cli/init.node.test.ts
  ● does not produce eslint errors or warnings

    expect(received).toEqual(expected) // deep equality

    Expected: ""
    Received: "DeprecationWarning: 'originalKeywordKind' has been deprecated since v5.0.0 and will no longer be usable after v5.2.0. Use 'identifierToKeywordKind(identifier)' instead.
    "

      165 |   )
      166 |   expect(eslint.stdout).toEqual('')
    > 167 |   expect(eslint.stderr).toEqual('')
          |                         ^
      168 | })
      169 |
      170 | test('errors and shuts down if creating a directory fails', async () => {

      at Object.toEqual (msw-api/cli/init.node.test.ts:167:25)

 PASS  test/node/msw-api/setup-server/life-cycle-events/on.node.test.ts
 PASS  test/node/msw-api/setup-server/use.node.test.ts
 PASS  test/node/msw-api/setup-server/scenarios/generator.node.test.ts

 RUNS  test/node/msw-api/setup-server/scenarios/response-patching..node.test.ts
[1]    87846 segmentation fault  pnpm test:node

I'm unfamiliar with msw (just trying to unblock things). I can go troubleshoot this, but I am maybe not the best one to do it, and I want to first check whether this is maybe already less opaque to somebody else. :)

[kettanaito]

@gthb, I've not seen these errors before, I'm afraid. At first glance, they seem like system-related errors unable to process ESM (?). None of the changes introduced in this pull request should be causing this. Let me try this branch locally to confirm.

[kettanaito]

I've reverted any changes outside of the typescript dependency range. Everything passes locally now (previously, had some weird segmentation issue during the pnpm test:node run). It's possibly a bug in the eslint-related dependencies. Let's see if this changes anything remotely.

[kettanaito]

Okay, the CI is green now. We'd have to update eslint module later.

I'd much like to couple new TS versions support with the deprecation of older TS versions but since it'd be a breaking change we cannot afford it at the moment. No worries, I will drop 4.4 and, potentially, everything prior to 4.8 in the next breaking release.

Thank you for working on this, @gthb! 👏

[gthb]

Okay, the CI is green now. We'd have to update eslint module later.

I narrowed it down, it's the tsup upgrade (to 6.0.0 or any later version) that causes the segfault. All tsup versions prior to 6.0.0 are fine. Both of the eslint upgrades are fine.

Installing tsup 6.0.0 vs 5.12.9 involves no differences in other packages (dependencies of tsup), so the problem is within (or is triggered by something within) tsup itself.

There are no mentions of “segfault” or “segmentation fault” in the tsup issue tracker, so this probably merits reporting!

[gthb]

There are no mentions of “segfault” or “segmentation fault” in the tsup issue tracker, so this probably merits reporting!

Reported in egoist/tsup#919

[azangru]

Could you please release a new minor version of msw now that this PR got merged in? Until a new minor version is released, it blocks projects depending on msw from updating to typescript 5.1 😞

[kettanaito]

@azangru, MSW is automatically released every 3rd day of the week:

msw/.github/workflows/release.yml

Line 5 in 4c7e952

- cron: '0 0 */3 * *'

I really need to write a notice about this somewhere and link it whenever people are asking.

I will issue a manual release right now to unblock everyone with this change.

[azangru]

Thank you 🙏