Hacker News Reader

Comment by systemvoltage | Hacker News Reader

I am struggling with this. I have made an Amazon storefront in React JS + npm package manager after watching this tutorial. I must have deleted the node_modules folder a dozen or more times and if you npm install again, it works! This is the kind of stuff that makes me wonder, how can I make a production worthy app without the fear of not being able to fix the dependencies!?

Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.

View on HN

Why would you default to using the non long term support version? Would you do that for, say, ubuntu?

It’s an easy blind alley to blunder down on some platforms. If one’s package manager defaults to edge versions and you’re just getting standard with a new language/framework via a tutorial, for example, this is how you learn there’s an LTS release the hard way. Homebrew users on Mac are common victims, but similarly Arch Linux or FreeBSD may trap the unwary (and for more besides than merely Node)

s/standard/started/

Why are there "not-LTS" versions are all?

So we can develop for them. A new version of, say, a programming language needs the ecosystem to come along with it.

I had no idea there was LTS and non-LTS versions of node.

C# doesn't have non-LTS versions. Java doesn't. C, C++, Haskell, OCaml don't. In OSes, Windows and Mac OS don't. I'm actually struggling to think of anything outside of Linux and Node that has this concept of "here's a major version that is marked LTS and here is a beta, but we're not going to call it beta, we're just going to call it an odd-numbered major version".

Windows does do LTS. So do Java, Django, Unity, and many others.

That said, node versioning has caused me a lot of stress over the last few years. Not sure if that's to do with the use of LTS specifically though.

When Microsoft calls a version of Windows "LTS", it means "this is an old version of Windows for which we're going to keep releasing security updates for the next 10 years", not "all more recent versions of Windows should be considered beta quality software".

I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.

Debian Sid. Anything with a master, edge, or nightly release. Safari Tech Preview, Chrome Dev Edition, Firefox Developer Edition. FreeBSD-CURRENT vs FreeBSD-STABLE. And every network or storage operating system I ever installed on a switch or router or SAN head or other appliance came in a variety of release trains, from Experimental-Will-Crash to GA(T) and every shade in-between.

> "another offender"

Be careful, it's a nasty fall off that high horse.

and re. these earlier remarks:

> Windows and Mac OS

Windows and Mac OS most definitely have experimental/preview releases and standard releases. Microsoft offer extended support options, and ultra-marathon ESU contract support for products as far back as Windows Server 2008.

Same goes for most commercial RDBMS. Heck, even Oracle has a preview release.

> anything outside of Linux or Node

Linux stopped using alternating version numbers in 2004, so I'm afraid your information there has passed even Microsoft's extended support period. For the curious, though, GNOME still uses the even/odd versioning as a lifecycle indicator, but has plans to abandon it this year. I hope Node will do the same, because of all the numbering styles this is certainly the most confusing.

As for Java, only a dyed-in-the-wool government bureaucrat could possibly love Java's approach to ecosystem engagement. "Let's have seven years of committee meetings and experimental feature flags for the new GC". Ugh.

Standing back, this just sounds like a grumble about terminology, because almost _everyone_ has some kind of leading-edge release and some kind of stable release, the only difference is the naming, and that doesn't seem to me the basis of a substantial complaint. If the core issue is inconsistencies about which one is installed by default, then that is a complaint I'd suggest best leveled at package managers, because there is no universe available in which every software project is going to somehow magically converge on a single lifecycle policy.

You are missing the point entirely. All of those examples you've listed are clearly marked in some notion of "prerelease". Even in the FreeBSD example, you're going to see that one version is labeled in such a way to make it sound safer. "Long-Term Support" labelling of one version says nothing openly about the unlabeled version.

It's exactly the lack of label on non-LTS versions I'm talking about. It has a real impact on people, looking at which version to install, and having no guidance that "this version not labeled in any special way, yeah, probably don't use that". And no, digging into the developer mailing list to figure out what the versioning malarkey a particular project is using is not a documentation of it.

Oh, no, I see the point, I just think it's an unproductive nitpick about an ultimately superficial complication. Labels aren't irrelevant, but they're pretty lacking in substance, and there are plenty of aphorisms about people who make assumptions based on surface details.

What's more, this gripe alone won't solve anything, since no-one is going to conform to anyone's expectations but their own in regards to release policy.

Because you'll just as easily stumble on other packages which are "bleeding edge", highly regarded, and require Node 15 features to run

Reply on news.ycombinator.com