For reference, I found the PR where you initially made that change a few years ago: #4805

^6.5.1 would also match 6.10.0 which has the change of internal dependencies in qs, and peer dependencies are not a solution for the UMD build per se.

Anyway the package is definitely compatible with a newer version of qs, or even without the qs dependency at all if you pass your own routing, so resolutions is a valid solution.

We're more likely to replace qs by an alternative dependency than update to the latest versions, sorry.

I'm a bit confused so I think I might be missing some context.

Looking at the code in node_modules, I think I'm getting a better picture of how the library is built. Please correct me if I'm wrong.

You're building:

• a cjs and a esm build that does not bundle the qs library (it is imported as an external library) => this would allow for what I'm suggesting, ie allow for all versions of qs v6 and let the app using the library decide which version will end up in the app bundle
• a dist build that bundles the qs library, which is the part that is concerning you

So here are a couple options that should work I think:

1. set qs@^6.5.1 as a peer dependency (which will be used for cjs/esm) and add qs@^6.5.1 < 6.10 as a dev dependency. The dev dependency will restrict the version used for building the dist build, while not restricting the version for any third-party app that is using the library
2. set qs@^6.5.1 as a dependency, but have the library's lockfile pin it to whatever version you want - this is a bit more of a pain to maintain though

that totally works, but for ESM and CJS we also don't want people to be forced to use the inferior version of qs that has the bundlesize penalty.

They're not being "forced" to do so if you leave the range wide enough.

The issue might be that it will default to installing the bigger version of "qs" though.

But one could argue that it becomes the responsibility of the library user to ensure they're using the right version.

As it is, people actually run the risk of having multiple versions of qs in their bundle, if they haven't noticed the issue like I did. So it ends up being actually worse.

qs is pretty widely used and I wouldn't be surprised if multiple other libraries out there were setting a newer version as a dependency.