Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

431–440 of 478 posts

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

#431

Post by habosa »

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 getting (unless I shrinkwrap which is uncommon).

In other stacks having your dependency versions float around is considered bad practice. If I want to go from depending on 1.2.1 to 1.2.2 there should be a commit in my history showing when I did it and that my CI still passed.

I think we miss the forest for the trees when we get mad about Node devs taking small dependencies. If they had pinned their version it would have been fine.

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

#432

Post by KMnO4 »

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…

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.

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

#433

Post by ulisesrmzroche »

hota_mazi wrote: post #405
Hokusai wrote: post #295

Earlier quoted context omitted.

I found it! :) I has a lot of content and insights. "Uncle" Bob Martin - "The Future of Programming" https://www.youtube.com/watch?v=ecIWPzGEbFc

That's not the source, it's the claim. There is zero evidence for his claim that the number of developers double every five years.

Off the top of my head, coding boot camps

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

#434

Post by tablethnuser »

This seems like an issue with semver. Its idealism is not compatible with actual human behavior.

The package devs clearly violated semver guidelines and npm puts a lot of faith in individual packages to take semver seriously. By default it opts every user into semver.

If you need semver to be explained to you bottom up (lists of 42 things that require a major bump) then you don't get semver. All you have to do is think: will releasing this into a world full of "^1.0.0" break everyone's shit?

This and left-pad are extreme examples. But any maintainer with a package.json who tries to do right by `npm audit` knows that there is an endless parade of suffering at the hands of semver misuse. Most of it doesn't make the news.

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

#435

Post by city41 »

earthboundkid wrote: post #428
city41 wrote: post #301

Earlier quoted context omitted.

You need to do this test if you are creating a promise implementation. That was my point, there is a reason code like this exists.

Why would an implementation need to test for it? ISTM that a framework may need to test for promiseness if it calls promises and functions differently, but it can and should be done as a utility in the framework, not as a separate package.

I agree with that. I have no idea why it’s in a separate package. But I can say that about many packages :).

It’s possible to just treat everything as a promise by wrapping results in Promise.resolve() but that can have performance implications that some franeworks might want to avoid by only going down the promise route when they have to.

For promise implementations, If the callback to then() returns a promise, the promise implementation detects that and resolves that promise behind the scenes: http://www.mattgreer.org/articles/promises-in-wicked-detail/...

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

#436

Post by balfirevic »

erulabs wrote: post #347

I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…

I honestly have no idea if you prefer Node.js or J2EE after reading this comment.

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

#437

Post by lukevp »

KMnO4 wrote: post #432
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…

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 doesn’t appear to be breaking to the maintainer but is in actuality. For example, suppose a UI library has a css class called card-invalid-data and wanted to rename to card-data-invalid. This is an internal change since it is their own css, but could break a library that overrode this style or depended on this class. I would consider this a minor version but it could still cause a regression for someone.

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

#438

Post by recursive »

jakear wrote: post #397
recursive wrote: post #391

Earlier quoted context omitted.

Not sure about that. https://nodejs.org/en/download/releases/

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.

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

#439

Post by TSiege »

KMnO4 wrote: post #432
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…

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.

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

#440

Post by RobertKerans »

jrochkind1 wrote: post #276
_630w wrote: post #214

Earlier quoted context omitted.

I wonder why people won't use yarn zero installs. They are great for having a reproducible builds and can work offline. You can have a CI and git hook which checks your code before deployment or pushing to git. Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.

What's "yarn zero installs"? Googling did not do it for me.

Google "yarn plug and play", rather than "yarn zero installs". There isn't much in the way of details outside of the main Yarn website -- now focussed on Yarn 2 -- which has the documentation (vs Yarn 1.n, which does not have plug and play and works the same as NPM, and has now moved to classic.yarnpkg.com)

(Edit: I'm not quite sure how this would have completely prevented the issue? P'n'p is very good and seems to be a real step forward for JS package management but surely the same issue could have occurred regardless?)

Post reply on HN