3 ms·

It seems to me that a lot of people are forgetting that when updating to next major version of a package, breaking changes are expected - that's the whole point

It seems to me that a lot of people are forgetting that when updating to next major version of a package, breaking changes are expected - that's the whole point of major version number in SemVer [1]. What they actually want is seamless updates (or never changing APIs, but that not possible in most situations, and also not what you want as a package developer - you want to be able to correct your API design mistakes). That requires a lot of work from the package developers. Look for example how people at Remix do it: breaking changes are hidden behind future flags [2], so you a user can turn them on one by one and adapt their code on gradually without surprises. Another solution is creating codemods for upgrades. But how many open-source package developers are willing do to this extra work? Same story with peer dependencies - they're completely fine, if package developers know how to use them. As always, don't be mad at React, don't curse Npm, it's not their fault. There is no great package without great effort. [1] https://semver.org/ https://semver.org/ [2] https://remix.run/docs/en/main/guides/api-development-strategy#unstable-apis-and-future-flags https://remix.run/docs/en/main/guides/api-development-strate...

eqvinox 2y ago
> It seems to me that a lot of people are forgetting that when updating to next major version of a package, breaking changes are expected No, I don't think that's the problem here. The author completely understands and accepts that a new major version will break their code. They're asking whether there's actually a benefit to these breaking changes. > seamless updates […] That requires a lot of work from the package developers. Well, the lower something is in the stack, the more likely developers seem to be to put in that work. The Linux kernel syscall API is sacred, so are most Win32 base interfaces. libc/VCRT almost as much. Python versions a little bit less. GUI toolkits and SSL libraries break a bit more frequently but tend to just be parallel install. But the more you move up the stack, the more frequent breakage you get. Same in the browser. Basic DOM is backwards compatible to the stone age, but the more things you pile on the more frequent API/update breakages become. It's really a kind of obvious logic, since the lower something is in the stack, the more things above it indirectly snake down dependencies, and the more pressure to not break things there is.

eqvinox 2y ago

> It seems to me that a lot of people are forgetting that when updating to next major version of a package, breaking changes are expected No, I don't think that's the problem here. The author completely understands and accepts that a new major version will break their code. They're asking whether there's actually a benefit to these breaking changes. > seamless updates […] That requires a lot of work from the package developers. Well, the lower something is in the stack, the more likely developers seem to be to put in that work. The Linux kernel syscall API is sacred, so are most Win32 base interfaces. libc/VCRT almost as much. Python versions a little bit less. GUI toolkits and SSL libraries break a bit more frequently but tend to just be parallel install. But the more you move up the stack, the more frequent breakage you get. Same in the browser. Basic DOM is backwards compatible to the stone age, but the more things you pile on the more frequent API/update breakages become. It's really a kind of obvious logic, since the lower something is in the stack, the more things above it indirectly snake down dependencies, and the more pressure to not break things there is.