Post · bonfire.cafe

cross-posting my little rant about #npm #npmattack #javascript #typescript stuff here:

Random NPM thoughts of the day:

The primary NPM registry should be obsoleted entirely ASAP
JSR does not do anywhere near as much as it should, and it's probably too late to fix.
A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
All packages MUST be ESM (JSR ok here)
MUST include docstrings on all publicly-reachable interfaces.
MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
MUST have a non-trivial README.
MUST be tied to a PUBLIC repo.
MUST NOT have install scripts (yeah sorry, the fight's over)
MUST clearly include a license, even if the license is "source available, not open source". This restriction MUST NOT limit to OSI's ridiculous list.
MUST have a name that is scoped to its publishing user/org (@foo/bar)All of the above constraints MUST be checked at publish time.

Furthermore, the registry MUST provide the following, based on this:

Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
Autogenerated API docs.
Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.
Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queue, overridden by [tbd?staff?]
Y'all aren't gonna like this but: package installation should be reasonably throttled. Both to keep costs down, and to encourage people to do something less lazy than "I'm just going to install all 2k dependencies on CI every time I push a docs change". It's wasteful and harmful for many reasons.

I think that's all I got off the top of my head for now.

There's honestly a lot of stuff that could be done on the client side to make life better, too, and y'all know I have a ton of thoughts on that, but I wanted to rant about registries for a bit, esp now that the NPM registry is crumbling.

Hermancy

@Hermancy@mastodon.social replied · last week

@zkat These are all good policies that GitHub i.e. Microsoft will never implement.

Your points are valid regardless but most big tech orgs hate standards like this, especially if they might cost something.

Big orgs don’t want secure well built software anymore. They want “hello world” ready in eighteen seconds and “shitty web app number one hundred squegillion” out within the month. Their policy is “it’s cheaper to pay lip service to quality than actually pursuing it”.

Donald Ball

@donaldball@triangletoot.party replied · last week

@zkat @baldur “Lower-traffic packages that have not had a new version in 6 months should be completely delisted.”

There are languages where useful packages are often completed and do not require constant updates.

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@donaldball @baldur if they’re that useful, they won’t be dead in the water. If they’re dead in the water, they’re not very useful

Donald Ball

@donaldball@triangletoot.party replied · last week

@zkat @baldur I invite you to review https://github.com/stuartsierra/component, and consider the virtues of a development culture that doesn’t fetishize frequent releases as a perverse signal of stability.

@r@glauca.space replied · last week

@zkat not entirely clear what your goals are (saw "quality" in the replies), but i see a few problems:

3. there exists a niche putting WASM modules on NPM. maybe you can make something separate for this, but it's a legitimate use case

6. what about native code dependencies? (this seems to be a perpetual problem that language-specific package managers just ignore)

4. doing this for usernames feels ripe for squatting and similar types of abuses/disputes, unless the conflict detection applies to only the combined (username, package) tuple

Philipp Tootloff

@kleinfreund@mastodon.social replied · last week

@zkat

> Lower-traffic packages that have not had a new version in 6 months should be completely delisted. They can be installed, with a warning printed.

Should this apply even for packages with 0 dependencies? Those, if they're considered feature-complete, should have no practical need to be updated unless there is a vulnerability in the package itself.

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@kleinfreund you mean 0 dependents? Packages that no one uses, and which have not been updated for a long time, are basically bitrotted.

Philipp Tootloff

@kleinfreund@mastodon.social replied · last week

@zkat No, I mean 0 dependencies. Why should a feature-complete package with no dependencies need to have published a new version to stay listed?

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@kleinfreund because runtimes evolve.

If the feature-complete package is popular enough, it won't have a problem staying listed. Low-traffic really does mean low-traffic. If there's barely anyone discovering and using it, then that means it's largely just taking up space in search results.

Ben Delarre

@bendelarre@mastodon.social replied · last week

@zkat with you on all of these points!

Would love to discuss more the throttling of package install. The 'best practice' dogma of not committing node_modules to source control has been so strong that I'm not sure we've taken a good look at why we are doing it. Once you eliminate post-install scripts and platform dependent binaries the decision looks a little different I think?

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@bendelarre yes, but you still have to deal with enormous, redundant diffs in your git repository.

Ben Delarre

@bendelarre@mastodon.social replied · last week

@zkat true. Is there another option? We use pretty aggressive caching in CI and pnpm with its central store helps on dev machines. That all helps, but still feels horribly wasteful to be installing dependencies on every CI run.

I haven't done native development professionally for a long time. Are there other paradigms web dev could draw from? In my embedded hobby work submodules and committing vendor dependencies seems common.

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@bendelarre I was actually working on a package manager that would obviate the need to reinstall dependencies every time. It was just a lot of (thankless) work and I moved on from the project. It would also make package installation basically instant

Alex Russell

@slightlyoff@toot.cafe replied · last week

@zkat This list is missing the big one: separate binaries for client and server, and server packages must never be offered for use in client-side bundles.

Tom

@serpentroots@hachyderm.io replied · last week

@zkat another one:

- vulnerabilities should be listed at the top of the page with a warning if the latest package version contains any.

1.3.6.1.4.1.61513

@xssfox@cloudisland.nz replied · last week

@zkat

> MUST include docstrings on all publicly-reachable interfaces.
Doesn't really help supply chain attacks

> MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
This is very limiting for packages that might depend on other packages that don't agree/can't be hosted on the repo

> MUST have a non-trivial README.
Some projects are trivial.

> Autogenerated API docs.
On the repo site??? This seems like mixed concerns

> Lower-traffic packages that have not had a new version in 6 months should be completely delisted.
Projects can be done and not need updates.

> Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account
People die. You need to factor this in.

> Top 1000 packages (maybe more) have all new publishes put on hold for 7 days, and placed into a public review queu...
No one reviews stuff. Staff reviewing is going to cost. Will delay security

Tom

@serpentroots@hachyderm.io replied · last week

@xssfox @zkat Go does the auto-generated API docs really well for all public types/functions. It's probably not as easy for something like npm but it would be really nice.

1.3.6.1.4.1.61513

@xssfox@cloudisland.nz replied · last week

@zkat this might not seem like much but it ends up being a burden on unpaid open source devs. Most of the requirements you have could be checked on client side.

Risotto Bias

@risottobias@toot.risottobias.org replied · last week

@xssfox @zkat this. asking open source developers (most of which it's /one person/) to do free work for a company's "supply chain" is gross.

software provided as-is and for fun. grown up registries with "demands" for maintainers should also include the novel concept of "stipends".

didn't the NPM founder lay off a bunch of people and then quit?

Kat Marchán 🐈

@zkat@toot.cat replied · last week

@xssfox Unfortunately, they can't "just" be checked on the client side. That's not how building a sustainable commons works. For some stuff, you really do need to set some ground rules about your shared space.

I also think it's ok for unpaid open source devs to just... decide the bar is too high and not publish things that don't meet these standards. I think it'll save them time, save them long-term headache, make them more secure, etc.

I say this as an open source dev who has and does maintain packages at the very top of the list of two different package ecosystems. I'm not some unempathic rando who's rolling in with an uninformed opinion. I want these constraints to be applied to anything I would publish. It would make my life better.

1.3.6.1.4.1.61513

@xssfox@cloudisland.nz replied · last week

@zkat most of the constraints don't even help supply chain attacks though. They just make the likelihood of a Jia Tan style attack more likely.

I feel like focusing on a stronger standard lib so people have much less of a attack vector / small area to audit would be a better start.

What your advocating for is closer to debian repos/packaging which isn't all that great

Bart Louwers

@bart@floss.social replied · last week

@zkat We also need to deprecate all bars and instead the replacement bars MUST serve free beer.

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.0-rc.2.21 no JS en

Automatic federation enabled