A one-line package broke `npm create-react-app` • Hacker News Board

Re: A one-line package broke `npm create-react-app`

#441

Post by yellowapple » Sun, Apr 26, 2020, 3:22 PM UTC

TSiege wrote: post #439

KMnO4 wrote: post #432

Earlier quoted context omitted.

That’s still the fault of the package developer. “^1.2.1” means “any version with a public API compatible with 1.2.1”, or in other words “only minor versions”. The whole point of semantic versioning is to guarantee breaking changes are expressed through major versions. If you break your package’s compatibility and bump the version to 1.2.1 instead of 2.0.0 then people absolutely should be upset.

I think you might be misunderstanding the above comment. The default behavior of `npm i ` is to add `" ": "^1.2.1"` _not_ `" ": "1.2.1"`. The point the commenter was trying to make is that the tool itself has a bad default which makes it easy to make mistakes. I would go so far as to argue that when `npm i` does not have the behavior a user would expect from a package manager in that regard.

And likewise, I think the point of that above comment is that such a change in default behavior wouldn't be necessary if package authors actually obeyed semantic versioning.

That is: "^1.2.1" shouldn't be a bad default relative to "1.2.1"; you generally want to be able to pull in non-breaking security updates automatically, for what I hope are obvious reasons, and if that goes sideways then the blame should be entirely on the package maintainer for violating version semantics, not on the package/dependency manager for obeying version semantics.

I don't have much of an opinion on this for Node.js, but the Ruby and Elixir ecosystems (among those of many, many other languages which I've used in recent years) have similar conventions, and I don't seem to recall nearly as many cases of widely-used packages blatantly ignoring semantic versioning. Then again, most typically require the programmer to be explicit about whether or not to allow sub-minor automatic version updates for a given dependency, last I checked (e.g. you edit a configuration file and use the build tool to pull the dependencies specified in that file, as opposed to the build tool itself updating that file like npm apparently does).

Re: A one-line package broke `npm create-react-app`

#442

Post by wutwutwutwut » Sun, Apr 26, 2020, 3:23 PM UTC

cerved wrote: post #415

wutwutwutwut wrote: post #205

Earlier quoted context omitted.

My development environment is my production environment.

F

I think you missed my point so let me clarify: If your job is to develop software, then your computer is your production environment. It's where you run your production - your development. This is hopefully separate from where your customers runs development.

Re: A one-line package broke `npm create-react-app`

#443

Post by yellowapple » Sun, Apr 26, 2020, 3:26 PM UTC

throwanem wrote: post #225

x86_64Ubuntu wrote: post #195

Earlier quoted context omitted.

And your example is why we have the "lol javascript trash amirite" chorus, because as you've noted these problems were solved decades ago. Yet for some reason, the JS and npm ecosystems always seem to have some dependency dustup once or twice a year.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

It ain't surprising, but rather just disappointing, that an ecosystem can't or won't learn from the trials and tribulations of other ecosystems.

EDIT: also, Node's more than a decade old at this point, so it is at least a little bit surprising that the ecosystem is still experiencing these sorts of issues.

Re: A one-line package broke `npm create-react-app`

#444

Post by yellowapple » Sun, Apr 26, 2020, 3:28 PM UTC

Aeolun wrote: post #427

hota_mazi wrote: post #404

Earlier quoted context omitted.

> The number of developers duplicates each 5 years You probably mean "double" here, but the bottom line is that there is zero data to back up that claim. He literally made up that number out of thin air to make his talk look more important.

It should be fairly simple to look up people describing themselves as developers in the census data I think?

Does the census actually track that? I just did the questionnaire last night online and it didn't ask me anything about my occupation.

Or did you mean something other than the US Census (e.g. GitHub or Stack Overflow or LinkedIn profiles)?

Re: A one-line package broke `npm create-react-app`

#445

Post by nitsky » Sun, Apr 26, 2020, 3:40 PM UTC

recursive wrote: post #438

jakear wrote: post #397

Earlier quoted context omitted.

Rephrase: people use new TS features much more often than they use new Node features.

That might be true in general, but I seem to run into problems with the two with about equal frequency. One of the recent ones I ran into with node was stable array sort.

Yes, npm package maintainers spend a lot of time on node version compatibility. Here is a quote from prettier on their recent v2 release:

> The main focus should be dropping support for unsupported Node.js versions.

https://github.com/prettier/prettier/issues/6888

Re: A one-line package broke `npm create-react-app`

#446

Post by _-o-_ » Sun, Apr 26, 2020, 3:44 PM UTC

foepys wrote: post #409

ashtonkem wrote: post #395

Earlier quoted context omitted.

Funny, I run an “enterprise” stack almost entirely made of Java. I wouldn’t trade it for NodeJS for the world. Making upstream changes indeed would be very, very hard. But I never have to make upstream changes because they’ve spent quite a large amount of effort on stability.

I'm also making enterprise-grade software with quite a few external dependencies. I had to email the developers of the biggest dependency multiple times because of bugs but they were all fixed within a few weeks in a new patch release. They also went out of their way to provide me with workarounds for my problems. In the NPM world you are on your own.

Why? You can email package maintainer just as well, or better yet - open an issue on GitHub.

Re: A one-line package broke `npm create-react-app`

#447

Post by dgellow » Sun, Apr 26, 2020, 3:45 PM UTC

turnipla wrote: post #412

dgellow wrote: post #293

As always: vendor your dependencies.

Good luck vendoring node_modules. Why are these threads filled with people who know nothing about node? npm and yarn both have lockfiles for this purpose. Vendoring only bloats your repos.

> Why are these threads filled with people who know nothing about node?

That’s a quite bad assumption from your part based on almost no information.

I don’t know about the rest of the thread but I’m personally quite familiar with node. A lock file doesn’t fix the same issues vendoring does. The lock file gives you an explicit list of version used, vendoring save the exact copies of the dependency with the rest of your code.

By vendoring anyone who is working on the project is using the exact same version of a dependency, AND you don’t have to care about an external provider (the registry being up, etc, that’s way easier for you CI too), AND you can review dependencies upgrade via git as if it was your code.

Of course that’s a mess when the JavaScript ecosystem has an infinite amount of dependencies for a hello world.

Re: A one-line package broke `npm create-react-app`

#448

Post by rroblak » Sun, Apr 26, 2020, 3:58 PM UTC

lukevp wrote: post #437

KMnO4 wrote: post #432

Earlier quoted context omitted.

That’s still the fault of the package developer. “^1.2.1” means “any version with a public API compatible with 1.2.1”, or in other words “only minor versions”. The whole point of semantic versioning is to guarantee breaking changes are expressed through major versions. If you break your package’s compatibility and bump the version to 1.2.1 instead of 2.0.0 then people absolutely should be upset.

Allowing any version drift of dependencies at all means that if you don’t check in and restore using the package lock file, you cannot have reproducible builds. The package lock files are themselves dependent on which package restore tool you are using (yarn vs npm vs ...) it’s also much too ambitious to believe that all packages in an ecosystem will properly implement semver. There may even be times where a change d…

> Allowing any version drift of dependencies at all means that if you don’t check in and restore using the package lock file, you cannot have reproducible builds.

This is the germane point in this incident.

The parent comment mentions that SemVer "guarantee[s] breaking changes are expressed through major versions". This is a common misperception about SemVer. That "guarantee" is purely hypothetical and doesn't apply to the real world where humans make mistakes.

The OP `is-promise` issue is an example of the real world intruding on this guarantee. The maintainers clearly didn't intend to break things but they did because everybody makes mistakes

Which points to the actual value proposition of SemVer: by obeying these rules, consumers of your package will know your _intention_ with a particular changeset. If the actual behavior of that changeset deviates from the SemVer guidelines (e.g. breaking behavior in a patch bump), then it's a bug and should be fixed accordingly.

Back to the parent's point about locking dependency version— I would add that you should also store a copy of your dependencies in a safe location that you control (aka vendoring) if anything serious depends upon your application being continually up and running.

Re: A one-line package broke `npm create-react-app`

#449

Post by nialv7 » Sun, Apr 26, 2020, 4:25 PM UTC

habosa wrote: post #431

I am one of the maintainers of a popular Node-based CLI (the firebase CLI). This type of thing has happened to us before. I think the real evil here is that by default npm does not encourage pinned dependency versions. If I npm install is-promise I'll get something like "^1.2.1" in my package.json not the exact "1.2.1". This means that the next time someone installs my CLI I don't know exactly what code they're getti…

Probably off topic, but just want to say cargo does the same things on the Rust side, and it has been annoying me to hell.

And it's even worse in cargo, because specifying "1.2.1" means the same thing as "^1.2.1".

Re: A one-line package broke `npm create-react-app`

#450

Post by 2OEH8eoCRo0 » Sun, Apr 26, 2020, 4:27 PM UTC

IAmEveryone wrote: post #142

2OEH8eoCRo0 wrote: post #109

Earlier quoted context omitted.

I'm a novice in this area but if your project relies on a bunch of external node packages why wouldn't you download them all and host them locally or add them to version control?

Adding them to your own version control is a nightmare: Your own work will drown in all the changes in your dependencies. The repository will quickly grow to gigabytes, and any operation that would usually take seconds will take minutes. It's also just not needed. Simply specifying an exact version ("=2.5.2") will avoid this problem. The code for a version specified in this manner does not change.

To me an even bigger nightmare is your entire project or product depending on some external resource you don't control.