Next.js: Dependency version restrictions

[eps1lon]

Reopens #2993. There was no reason given why they are pinned to patch versions.

Feature request

• loosen dependency version restrictions

Is your feature request related to a problem? Please describe.

• node_modules/ bloat
• patches and features take more time to propagate downstream

Describe the solution you'd like

• pin to major version (i.e. ^)

Describe alternatives you've considered

• pin to minor version (i.e. ~)

Additional context

yarn check report concerning next. This is run in a monorepo for a component library that uses next for documentation.

warning "next#@babel/plugin-proposal-class-properties#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-proposal-object-rest-spread#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-syntax-dynamic-import#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-transform-modules-commonjs#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-transform-runtime#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/preset-env#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#autodll-webpack-plugin#webpack@^2.0.0 || ^3.0.0 || ^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#babel-loader#@babel/core@^7.0.0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#babel-loader#webpack@>=2" could be deduped from "4.29.3" to "[email protected]"
warning "next#friendly-errors-webpack-plugin#webpack@^2.0.0 || ^3.0.0 || ^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#@babel/plugin-proposal-class-properties#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-proposal-object-rest-spread#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-syntax-dynamic-import#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-transform-modules-commonjs#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/plugin-transform-runtime#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#@babel/preset-env#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#autodll-webpack-plugin#webpack@^2.0.0 || ^3.0.0 || ^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#babel-loader#@babel/core@^7.0.0" could be deduped from "7.2.2" to "@babel/[email protected]"
warning "next#babel-loader#webpack@>=2" could be deduped from "4.29.3" to "[email protected]"
warning "next#friendly-errors-webpack-plugin#webpack@^2.0.0 || ^3.0.0 || ^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#webpack-dev-middleware#webpack@^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#webpackbar#webpack@^3.0.0 || ^4.0.0" could be deduped from "4.29.3" to "[email protected]"
warning "next#@babel/plugin-proposal-class-properties#@babel/plugin-syntax-class-properties#@babel/core@^7.0.0-0" could be deduped from "7.2.2" to "@babel/[email protected]"

Switching from exact version matches to major matches reduces the size of my node_modules from 837MB to 785MB. While this isn't much it is still I/O that has to run on install. Every other next version installed locally increases the overall bloat.

[Janpot]

I saw some tickets where it's planned to bundle the dependencies with ncc and circumvent semver altogether. But maybe that's just planned for some dependencies only?

[timneutkens]

TLDR would be Next.js broke about 5 times (probably more) in very big ways because of unpinned dependencies. Even recently with pinned deps (not trying to call anyone out here, just giving examples of known breakage):

• webpack-hot-middleware broke HMR in a minor version
• terser-webpack-plugin broke by publishing a major change as patch version
• terser broke through publishing a major change as patch version
• webpack broke through acorn updates (unpinned)

So there is no good reason not to lock the dependencies as of right now.

By pinning dependencies we can at least to some degree guarantee everything works with Next.js as our test suite is very extensive.

Also from reading those yarn check messages it seems like you're installing babel and webpack in your dependencies 🤔

[timneutkens]

We're actively working on dropping most unneeded dependencies and making Next.js smaller.

[eps1lon]

Also from reading those yarn check messages it seems like you're installing babel and webpack in your dependencies

Yes. We have a monorepo where library code and code for the documentation lives side by side.

I'm not sure that you should pin those dependencies. While it's nice that you curate transitive dependencies those dependencies should publish patches if they break semver.

Imagine every package would follow your dependency policy by not trusting version strings. What if a dependency A of your package would use an exact match for package B. Now a bug in B causes a bug in your package. You have to wait for A to use the patched B but have to explain in the meantime to your users that there is nothing you can do.

[Janpot]

So there is no good reason _not_ to lock the dependencies as of right now.

Well, if you don't lock dependencies in your lib, it still leaves me the choice in my application to decide whether I want to lock dependencies or not, whether through package-lock file or ncc or anything else. By locking dependencies you take away this choice, and you also actively go against the solutions (lock files) that package managers have put forward to defend against semver violations. And I think these are pretty good reasons to _not_ lock dependencies.

That being said, having been bitten by at least three semver contract violations in the past 2 weeks, I'm very sympathetic towards your frustrations.

May I also add the anecdote that relying on patch version updates instead of locking dependencies could have saved my company from having to pay out a considerable bug bounty with the XSS issues of the [email protected] release.

[TxHawks]

So there is no good reason _not_ to lock the dependencies as of right now.

There is also the issue of bundle duplicates. For instance, any app using react-apollo is going to end up with a duplicate of prop-types, because Next uses a pinned version while react-apollo does not.

[eps1lon]

So there is no good reason not to lock the dependencies as of right now.

@timneutkens I'm curious how you come to this conclusion while virtually the whole ecosystem disagrees with you (most libraries pin to major, very few to minor).

The current practice causes issues such as mridgway/hoist-non-react-statics#78