fix: add graphql to "peerDependencies"

[THETCR]

• Related to 2.4.0 Main entry point still exports handlers (i.e: GraphQLHandler) #2247, Vitest tests fail with error "Cannot find package 'graphql' imported" in v2.4.0 #2248

[kettanaito]

Thanks for fixing this! 👏

[kettanaito]

Released: v2.4.1 🎉

This has been released in v2.4.1!

• 📄 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.

[pascalmann]

Not work for me.
grapql was added to devDependencies (so no installed in my repo), but is still imported (lazily), even if I not use it.

[thepassle]

This should've been a breaking change (and it did cause breakage for some of our projects). If people import something from 'msw', it'll still hit the dynamic graphql import (even if we don't use anything graphql related from msw), which now doesnt get automatically installed because its only a peer dependency.

Thankfully I can work around it by rewriting our import from 'msw' to 'msw/core/http', since we only use http and not graphql, but more people will start running into this issue as well.

[kettanaito]

If people import something from 'msw', it'll still hit the dynamic graphql import (even if we don't use anything graphql related from msw)

This is the part that's confusing. How? Dynamic imports are by definition a part of your runtime. I don't suppose the browser extracts that dynamic import, puts it on the root scope, and then evaluates it. That mustn't happen, otherwise I see no point in a dynamic import as a feature.

Removing a graphql dependency is fix by design. You shouldn't be installing that package if you aren't planning on mocking anything GraphQL. As such, it was shipped as fix. The fact that the first few iterations of that fix are problematic in certain environments is a separate discussion.

I am welcoming reproduction repos at this point because none of my prior testing caught this. Here's where I've tested these fixes:

• Vitest ESM
• Vitest CJS
• Jest ESM
• Jest CJS
• webpack-based project

I hope that anybody reaching out understands these changes are done in good faith. I cannot physically test every existing combination of your tooling. Yes, things may break. You are more than welcome to pin the MSW version and go on with your life. If not, you should contribute with discussions, suggestions, and pull requests. Thanks.