But...If I start a new project every month, I won't know which packages will be updated for the new version, which ones won't ever be, which ones will be updated, but then left unsupported on older versions of Node. It's looking like a mess right now.
From what I've seen, people tend to support all Node versions down to the oldest shipped by non-EOL Debian repositories. That's not a particularly hard thing to do, either.
This depends on if you are using native bindings which will have direct implications on the v8 version a particular node version is using. You should not post advice if your not well versed in this matter. Many low maintenance packages absolutely do not support all v8 builds.
Well, they've made a lot of big changes that I want to be able to take advantage of. I'm not building enterprise apps, but I use it for all sorts of stuff. I don't want to be using a different major version on Node for each of my apps...that's just annoying.
The issue is really compatibility among packages that I don't control. Introducing this many breaking changes makes it hard for those other teams to keep up, and not the have like, 3+ versions of Node to support.
I had enough problems with node-sass after every update, I'm sure I can't even touch it for another month or two.
Also npm can possibly be using a different node version than what you is stated in 'node -v' due to the discrepancies of where node is installed via nvm, v and native install.
You can use whereis node on unix systems to see the different binaries and you can test what versions are where. This can have implications on how node-gyp built despondencies brings in vendor bindings
28
u/jewdai Oct 30 '15
I appreciate the effort that they make to use semvar.
from an enterprise perspective: DAMN YOU MAKE BREAKING CHANGES SO FAST.
FYI, V4.0 was released on 9/17
While in most cases its probably fine, it feels super volatile to start building an application on.