I think from a practical perspective the node engine requirements in package.json can also be considered a part of the version.
The definition of breaking change is very subjective in general (if my code is listing all the functions in your module, even adding a function is considered a breaking change if you’re too strict!), so there is room for practical considerations when you change things
I think from a practical perspective I’d be annoyed if I upgraded a package by a point release and things broke because I’m on an older version of Node.
The thing that happens (at least nowadays, I don’t know when the functionality is introduced) was that if a library specifies engine in the package.json, then that gets checked.
Your system wouldn’t break, the installation of the library would fail (and it wouldn’t even get there because npm would pick a supported version of the library, i.e. the last one to support the version of Node you’re on).
So if you have a caret-versioned dependency on a library, it will pick the highest-versioned library release that is still in that major version, but with the right level of engine requirements. The tooling prevents you from picking up the “wrong” node version.
The Rust ecosystem doesn’t consider minimum-supported-rust-version to be a semver-major bump, but Rust can pull it off because the compiler is very backwards-compatible, so everyone is on the latest, and there isn’t even an LTS release.
Node.js unfortunately does make breaking changes. The breakage is usually small, but when you have so many deps, something always hits it. This means that long-term projects that can’t rewrite on a whim need to stay on LTS, and need deps to stay compatible with it.
But it is a breaking change so I think packages are doing the right thing.
I think from a practical perspective the node engine requirements in package.json can also be considered a part of the version.
The definition of breaking change is very subjective in general (if my code is listing all the functions in your module, even adding a function is considered a breaking change if you’re too strict!), so there is room for practical considerations when you change things
I think from a practical perspective I’d be annoyed if I upgraded a package by a point release and things broke because I’m on an older version of Node.
The thing that happens (at least nowadays, I don’t know when the functionality is introduced) was that if a library specifies
enginein thepackage.json, then that gets checked.Your system wouldn’t break, the installation of the library would fail (and it wouldn’t even get there because
npmwould pick a supported version of the library, i.e. the last one to support the version of Node you’re on).So if you have a caret-versioned dependency on a library, it will pick the highest-versioned library release that is still in that major version, but with the right level of
enginerequirements. The tooling prevents you from picking up the “wrong” node version.Interesting, I didn’t know that. Is that documented somewhere?
The Rust ecosystem doesn’t consider minimum-supported-rust-version to be a semver-major bump, but Rust can pull it off because the compiler is very backwards-compatible, so everyone is on the latest, and there isn’t even an LTS release.
Node.js unfortunately does make breaking changes. The breakage is usually small, but when you have so many deps, something always hits it. This means that long-term projects that can’t rewrite on a whim need to stay on LTS, and need deps to stay compatible with it.