Hacker News Reader

Comment by seniorsassycat | Hacker News Reader

I think there's a lot of room to innovate in the JavaScript package manager and registry space.

• support for optional features and dependencies tied to them, ala cargo. How many npm vulnerabilities are introduced thru the command line parser of a package you only use as a library?

• step away from packag.json. It's fine to keep it for the registry or even runtime, but development should use a file that supports comments.

• some automated version compatibility enforcement via typedefs or registry side tests.

• packages with more than one artifact so types, original source, and platform native artifacts can be published in one package but download only when needed.

View on HN

• that’s a solved problem: packages shouldn’t bundle CLI tools. Sindre Sorhus has been separating “CLI” from “API” for many years. “Unused dependencies” in general isn’t a solvable problem because a dependency might only be used if a certain parameter is passed. By the time that piece of code is reached, you either have it installed or it’s too late.

• that’s an issue that never got solved for the same reason: “package.json is never going away so we won’t add more ways to do the same thing” — ok so node/npm is going to suck forever, fantastic.

I think feature dependencies are better modeled than simple package splitting.

> For example, let’s say we have added some serialization support to our library, and it requires enabling a corresponding feature

> In this example, enabling the serde feature will enable the serde dependency. It will also enable the serde feature for the rgb dependency, but only if something else has enabled the rgb dependency.

https://doc.rust-lang.org/cargo/reference/features.html

It sounds better to install foo { features = serde } than foo, @foo/serde, and @bar/serde.

Npm has optional dependencies and there are libraries that error when you use a code push that requires them. Features would formalize that pattern and improve it with clear errors, and composability.

Why would you need comments in package.json?

I felt like I wanted this some times, but always concluded that the "scripts" commands should be self-explanatory.

There are also plenty of metadata fields.

And for detailed descriptions, why not just but a README.md next to it?

I think here, D. Crockfords original motivation for not allowing comments in JSON pays off perfectly well. If package.json allowed comments, they'd already have been abused as metadata.

Also, as someone who sometimes has a hard time coding and naming things concise and to-the-point: there just should be no need for comments in this file.

I know what I'm looking for in there and in which fields. Comments would clutter the file and encourage silly comments such as "this command starts a local development server, compiles your code using HMR, writes its output in folder XY, listen on port Z, etc etc". This can go into a README. At best, the commands should be self-documenting.

Why do you have dependency x? Why is it pinned to ^14 and not upgraded to 15?

I don't want comments as pragma or metadata, I want human readable explanations why.

This is a good example and I pondered it while writing the comment you replied to.

But my conclusion in this case is:

If there is some issue with breaking changes that prevents updating, or a deliberate decision for a certain version for a certain reason, it should be explained in a README and in the former case, the package manager should point out the conflicting dependencies in case you try to update.

https://docs.npmjs.com/cli/v10/configuring-npm/package-json#...

> support for optional features and dependencies tied to them, ala cargo.

For those of us who relies on trunk-based-development and feature flags, lack of this feature has been major pain! I can't remember how many times we had to keep a feature in a branch because it needs a change in package.json.

Reply on news.ycombinator.com