Support TypeScript 4.8

[CreativeTechGuy]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 14 or higher

Browsers

Chromium (Chrome, Brave, etc.), Firefox, Safari

Reproduction repository

N/A

Reproduction steps

N/A

Current behavior

When trying to update TypeScript to 4.8 (Just released today), we are warned that msw has a peerDependency range for typescript of >= 4.2.x <= 4.7.x. As such, it's a pain to force update TypeScript. There's no reason that msw should restrict the maximum TypeScript version we can use in our projects.

Expected behavior

It looks like this can be traced to msw features that require a minimum TS version (eg: #429).

Two solutions:

• Easy quick fix: Specify a minimum TS version in the peerDependencies but no maximum version
• Better long-term fix: Use the package.json typesVersions field to specify different type declaration files depending on the version of TS that someone is running. So if msw wants to use a new feature, they can create a new version of the types which is only used by users with compatible TS versions installed.

[NullVoxPopuli]

can a supported TS support matrix be added to C.I.?
For example: https://github.com/NullVoxPopuli/ember-resources/actions/runs/2923658244

[kettanaito]

Hey, @CreativeTechGuy. I'm sorry to hear about your painful updating experience.

The thing is, TypeScript is a dependency like any other. Only, TypeScript is released in this completely strange way. Did you know that minor versions of typescript indicate breaking changes? Yeap. So per semver, and common sense, depending on 4.x is a terrible idea. We've been beaten by this in the past, and that was the main motivator to introduce explicit TypeScript version support.

You can find the versions MSW supports officially in this matrix:

msw/.github/workflows/ci.yml

Line 47 in b93aca9

ts: ['4.2', '4.3', '4.4', '4.5', '4.6', '4.7']

We run type compilation on each change with all those versions to ensure there are no regressions introduced. You can also notice that 4.8 is, respectively, not in the matrix.

If you want to have 4.8 support, you can tackle it head-on:

1. Create a pull request that adds 4.8 to the supported TypeScript versions martix;
2. See the tests pass. If they do, we've got the support! If they don't, help us adjust our code base so that the TypeScript compiler would be happy with it.

Hope this answers your question. I'm going to rename this issue to "TypeScript 4.8 support" as we are not going to migrate from the explicit TypeScript peerDependency versions any time soon.

[kettanaito]

Oh, I've just noticed that @dargmuesli has opened a pull request that adds the 4.8 support! #1375

That's exciting. Let's see what the tests tell us.

[CreativeTechGuy]

Hi @kettanaito! Yes I am aware that TypeScript doesn't follow semver and both minor and major versions are breaking changes. It's peculiar though that msw is the only dependency out of hundreds that I've checked which limits the maximum TypeScript version which can be used. While TypeScript can have breaking changes at any point, they rarely do (and the breaking changes would likely not impact msw consumers). So this is likely going to cause more pain more often rather than actually catching a real breaking change.

For completeness: I'm wasn't suggesting depending on 4.x since that means nothing to TypeScript, but rather >= 4.2.

We've been beaten by this in the past, and that was the main motivator to introduce explicit TypeScript version support.

Can you link to what you are referring to? I'd love to look into this more since this is the first time I've ever heard about a library needing to restrict the maximum TypeScript version that their consumers use.

[kettanaito]

While TypeScript can have breaking changes at any point, they rarely do (and the breaking changes would likely not impact msw consumers)

I tend to disagree here. I recall migrating to the next minor version a couple of months back and it was a huge pain for me, as the consumer. The fact that others don't limit the TypeScript version doesn't mean that specifying a supported range is bad at its core. You need to look at their use cases and how their code is consumed.

People consume MSW in TypeScript projects and automatically become dependent on MSW's type declarations being compatible with whichever version of TS they're using. If there's a type violation, their entire app compilation breaks. Ouch.

For completeness: I'm wasn't suggesting depending on 4.x since that means nothing to TypeScript, but rather >= 4.2.

>= 4.2 is exactly the permissive range I'm talking about.

Can you link to what you are referring to?

You can learn more about the issues we've faced in the pull request that introduced the original typescript as peer dependency: #985. And although the issue was a 3.9 vs 4.2 versions mismatch, TypeScript can break the way it compiles your code between minor versions without a second thought. We don't want that to happen to our consumers.

I can also phrase it a little differently: I'd rather have a strict peer dependency policy than have to spend my time on issues where people are using the bleeding edge TypeScript and complaining that MSW breaks things for them. This creates two quite distinct kinds of thinking:

• Damn, my app broke out of the blue because of this lib.
• Oh, so they only support <= 4.7 and I'm on 4.10. Makes sense. Maybe raise a suggestion to support it? Opening a pull request also doesn't sound like a bad idea.

Because, in actuality, we can give 0 guarantees that MSW will compile on any minor version of TypeScript. Those versions ship breaking changes by definition, and rightfully so. How can the library promise automagical compatibility with whichever range of versions? Keeping in mind how TS is released, it's the same as stating:

{
  "dep": "*"
}

I wouldn't want to maintain that kind of software, to be honest.

[CreativeTechGuy]

Got it. Thanks for explaining.

I see it this way. TypeScript has a new major version every few months. It seems like once in the past year there's been an issue with msw as a result. The maintenance overhead of having to manually update msw to each new TypeScript version and blocking every consumer from updating until you do is far more than occasionally having to fix a bug from the latest TS version breaking something. Because importantly, there's no way that a TypeScript issue will cause any runtime impacts on the consumer. It would, at worst, break their build and so they'd just downgrade and report the bug.

I guess it's good that msw gets enough maintenance support that things like this are updated quickly. Eventually there'll be a day when maintenance slows down or stops completely and an issue like this will quickly make the package unusable even if it otherwise would have worked just fine.

Seriously appreciate the discussion! 😃

[kettanaito]

TypeScript is an optional peer dependency. The way its version mismatch is handled is purely up to the package manager you're using. I wouldn't say it breaks projects. If anything, you can disable the peer dependency warning and try things out.

But I get where you're coming from. I came to the conclusion that we can only promise support for those TS versions for which we have automated tests. Having to try out all the possible versions that may have issues is insane. Have a CI—have proof! From this perspective alone, removing a version range while deliberately keeping a fixed and known matrix of supported versions seems wrong. People complain, being confused because we don't specify which versions are officially supported. The only useful place to specify that is package.json.

TypeScript has a new major version every few months

That's precisely why I'm tentative to have a loose version range. I don't want to get a potential issue every time TS does a release. Once again, I'm much more comfortable with closing an issue on a TS version that has no official proof of support or accepting a pull request for it. Both come from my wish to minimize the amount of time I spend on the issues. I was actually going to close this one as well, suggesting opening a pull request. But since one is already open, I left it intact.

But I don't agree with the points presented still. What we have, effectively, is this:

• MSW depends on a third-party package.
• That package is released often.
• MSW has a fixed version range on that package to guarantee version support.

Sure, having to bump dependencies when updating that package sucks. But that's sort of the path for breaking changes, isn't it? You can't rely on that there are no breaking changes between versions that clearly indicate a breaking change. So the entire request comes down to:

Can you not specify an exact range for this third-party package because whenever I update to a breaking version MSW stops working?

That's the point of breaking versions and type ranges. TypeScript is not a special sunflower here (it's just released like one). While it may feel like a nuisance, it's a regular dependency update cycle, and all tools go through one when their dependencies get a new breaking version.

[CreativeTechGuy]

Thanks for this! At the very least I've learned a new perspective which is always valuable. Appreciate it!

[kettanaito]

Here's a recent example of how migrating from 4.7 to 4.8 breaks things: https://github.com/mswjs/msw/runs/8058492714?check_suite_focus=true. Looks like TS has changed the way types comply with the generic types. Now, in order to officially support 4.8, we need to rewrite our source code so that 4.8 is happy and all the previous versions are as well. Volunteers are welcome!

[kettanaito]

Released: v0.46.0 🎉

This has been released in v0.46.0!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i msw@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.