Comment by officialchicken | Hacker News Reader

Comment by officialchicken | Hacker News Reader

officialchicken

It's been almost 2 years since the great left-pad debacle[0]. The last major npm issue[1] was less than 2 months ago. While the underlying npm registry security issues will remain for a while (and other languages don't seem to have these issues with their package managers), there doesn't seem like there's too much I can do other than use yarn. And hope an alternative registry will appear.

Since I 'vote' with my code - this migration page has been helpful today - and I hope it will help others: https://yarnpkg.com/lang/en/docs/migrating-from-npm/

It took me ~5 mins to migrate all of my code from npm to yarn. But I don't have complex CI tasks either.

I use ncu to check updates every couple of days, sometimes more frequently. To further distance myself from npm, can anyone comment on the pros/cons of github repo paths instead of package names in package.json?

[0] https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos

[1] https://github.com/npm/registry/issues/255

*edit: formatting

Github paths can change way more easily than npm packages, users can rewrite git history + break your stuff and versioning when using it with npm is horrible. NPM also now protects projects from namesquatting and prevents you from deleting them when multiple projects depend on them.

How does NPM protect from namesquatting now?

http://blog.npmjs.org/post/168978377570/new-package-moniker-...

The left-pad debacle was a registry issue but the current issue is an npm client issue. In my experience, NPM 5 client versions have been shaky and unreliable, and there are problems with popular ecosystems like react-native [0]. I always roll back to npm 4, even on node 9.

[0] https://github.com/facebook/react-native/issues/14209

The quality of what's being delivered since version 5 leaves a lot to be desired. They should really more people to their team and someone better since a lot of people depend on this code. Also, what's up them not understanding how semver works and releasing a pre-release code as the regular version. That's pretty basic man and rarely someone is OSS fucks up this badly actually.

dist-tags/release channels are far superior to classic semver pre-releases.

What is the difference between an unstable and a stable version? Testing by users. So as soon as enough users have tested / enough time has passed without issues, an unstable release becomes stable. In the best case nothing about the code needs to change, the release just needs to be promoted to the stable channel / dist-tag. That is pretty common practice for a lot of software and especially packages on npm.

With dist-tags, you can still make the versions meaningful. Between unstable versions, you can still express in semver terms what type of release it is (patch/minor/major). In classic prereleases, that is not possible. There is no semantic relationship expressed between a -alpha.1 and -alpha.2. Was it a bugfix? Does it add a feature? You don't know.

The issue is that npm did not mention in their blog post that 5.7 was released on the unstable `next` channel. The issue is not release channels in general.

I agree with most of what you said.

> That is pretty common practice for a lot of software and especially packages on npm.

This is mostly what I have a problem with. Almost everyone is other ecosystems do not do something like this and there is a very good reason for it. Why not just follow a known and standard process of releasing things. https://twitter.com/maybekatz/status/966730802187792386

Even the NPM dev acknowledge the current process to be faulty and are considering switching to use pre-release tags.

and that using npm upgrade -g npm ignores the the @latest and @next release channels.

I can also recommend using NSP [0] to check your .lock files for security issues, for what it's worth.

[0] https://disjoint.ca/til/2017/11/10/managing-package-dependen...

> I use ncu to check updates every couple of days

You can use "yarn outdated" for that.

and "yarn upgrade-interactive --latest"

As far as I know it's not feasible to use Github repos instead of npm, at least for client-side code. Most packages are compiled from ES6 (or typescript, jsx etc) to ES5, and the generated code (which is what you want in your project) is usually not included in the git repo.

Reply on news.ycombinator.com