Discussion
Loading...

#Tag

  • About
  • Code of conduct
  • Privacy
  • Users
  • Instances
  • About Bonfire
Jan Lehnardt :couchdb:
Jan Lehnardt :couchdb: boosted
Kat March谩n 馃悎
@zkat@toot.cat  路  activity timestamp last month

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

Random NPM thoughts of the day:

  1. The primary NPM registry should be obsoleted entirely ASAP
  2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
  3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
  4. All packages MUST be ESM (JSR ok here)
  5. MUST include docstrings on all publicly-reachable interfaces.
  6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
  7. MUST have a non-trivial README.
  8. MUST be tied to a PUBLIC repo.
  9. MUST NOT have install scripts (yeah sorry, the fight's over)
  10. 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.
  11. 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:

  1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
  2. Autogenerated API docs.
  3. 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.
  4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
  5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
  6. 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?]
  7. 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.

  • Copy link
  • Flag this post
  • Block
Kat March谩n 馃悎
@zkat@toot.cat  路  activity timestamp last month

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

Random NPM thoughts of the day:

  1. The primary NPM registry should be obsoleted entirely ASAP
  2. JSR does not do anywhere near as much as it should, and it's probably too late to fix.
  3. A proper successor must only support "standard" JS, though temporarily accepting "strippable types" is ok rn
  4. All packages MUST be ESM (JSR ok here)
  5. MUST include docstrings on all publicly-reachable interfaces.
  6. MUST NOT include any type of dependency other than a named registry dependency with a semver version (no git deps etc)
  7. MUST have a non-trivial README.
  8. MUST be tied to a PUBLIC repo.
  9. MUST NOT have install scripts (yeah sorry, the fight's over)
  10. 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.
  11. 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:

  1. Full browsable (published) package sources, right on the site. With linkable paths. None of this absolute trash NPM decided to do.
  2. Autogenerated API docs.
  3. 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.
  4. Usernames/org names and package names must employ a suitably-aggressive levenshtein distance for potential conflicts. This should be aggressive.
  5. Packages cannot be transferred between accounts, and it's against policy to allow others access to your personal account. Orgs can work around this.
  6. 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?]
  7. 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.

  • Copy link
  • Flag this post
  • Block
Emelia 馃懜馃徎
@thisismissem@hachyderm.io  路  activity timestamp last month

Pro-tip for npm: rather than using a classic access token in your ~/.npmrc file, generate a granular access token that only has read permissions.

That way if something does compromise you, they only get access to the read token and cannot publish on your behalf.

#npm #npmattack

Emelia 馃懜馃徎
@thisismissem@hachyderm.io replied  路  activity timestamp last month

Also, npm now supports trusted publishing: https://docs.npmjs.com/trusted-publishers

This means you don't need a static token in your CI/CD configuration anymore.

#npm #npmattack

  • Copy link
  • Flag this comment
  • Block
Emelia 馃懜馃徎
@thisismissem@hachyderm.io  路  activity timestamp last month

Pro-tip for npm: rather than using a classic access token in your ~/.npmrc file, generate a granular access token that only has read permissions.

That way if something does compromise you, they only get access to the read token and cannot publish on your behalf.

#npm #npmattack

  • Copy link
  • Flag this post
  • Block
Log in

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.3.13 no JS en
Automatic federation enabled
  • Explore
  • About
  • Members
  • Code of Conduct
Home
Login