Post

npmjs.com used to link to the package directory when it was contained in a sub-directory of a monorepo. It no longer does and makes me so angry that they made the UI purely worse when they changed it

Integrate auto-generated type docs that shows exports, classes, functions, interfaces, etc. inferred from TypeScript and/or JSDoc. Inspiration: rustdoc or JSR It doesn't have to be as complex as rustdoc, but even something simpler, like JSR has, would be *chefs kiss*.

I’ve always wanted (mostly) a better API for the registry info (packages, download count, etc). Their website is also incredibly basic, file browser sucks (doesnt push to history api so going back drops your current viewed dir/file).

Weird flow but sometimes I need to check what version of a given dependency a package uses between a range of versions (usually installed to latest). Manually doing this is tedious af.

- Code tab should use URL state (eg: /package/:pkgName/code/?path=dist/index.js#L32-47), and not break the back button - Dependencies tab should pull a total count of sub-dependencies (ie: how much do I pull in from this one dep?) - Dark mode This looks interesting as a temporary fix:

I’ve asked this for ages now, it would be good to see dependents ordered by most downloaded. That way, when a breach happens you can quickly see where the next biggest attack surface is.

You can look at the "provenance" deployment logic for jsr, I like it a lot: You go there, say "create new package", then add your GitHub repo name + your username or so. Finished. GitHub builds from there are allowed to publish to jsr. Nice!

i will say that it is an absolute nightmare to publish and use private packages on npm, to the point where we switched to nuxt layers hosted in the cloud with our own auth

There's no way to check if you can claim a package name without trying to publish. Npm's name similarity policy is naive and considers any two packages the same if they contain the same letters, separated by any number of dashes/underscores/dots . ABC, a-bc, a.b.c, a____b-c are all "similar"

If you have a legitimate reason you can email support@npm and they may be able to unlock publishing of a specific package, especially if you're the maintainer of related names (e.g. if you publish `foo` and wanted `foo-x` but it got blocked, they can unlock it).

(though I realise there may not be anything you can do here if you're beholden to the npm API)

in fact ... it's possible to publish a new package through the ui (added earlier today!), and we do check if there are collisions, approximating npm's algorithm...

i literally had an experiment for a new "npmjs" to potentially make something like `npm add nuxt.com` or `npm add nuxt.com/package` the mainstream thing to be done. this would help us be more decentralized and we'd get rid of the fights over npm package names already being taken.

did not continue it because the scheduel went a bit harsh, but would love to explore it again.

If by admin flows you mean things like publishing packages… I’ve published one package to npm and no other experience in tech has made me feel more scared and stupid. The sheer number of options for how you build and distribute an npm package is absurd. I ended up getting a friend to help me.

♻︎ reposts appreciated for reach ...

npmjs: - the UI is too basic, and has no dark mode - very poor data visualization resources (the lonely sparkline for downloads is not enough)

this needs to be native

No atproto support

lol, clearly you struck the nerve with this question. Would love to hear what your "reasons" are if you care to share.

here are my 'reasons' not meant as a criticism of npm, to be very clear!

I really want better views of dependents, to do things like: - Sort by downloads - Filter be version This would let me find the biggest dependents of out-of-date versions of our packages and help them upgrade.

Yes! I have one old package that gets 1m downloads/week and I have no idea where they're coming from because the UI doesn't show it

You can try github.com/Fuzzyma/e18e.... It let's you query dependent packages. We use it in the e18e community to know where packages are used to replace them with alternatives

I would tell[asking for passkey]you my frustrations[asking for passkey]but there's some[cloudflare are you a bot]thing kinda gett[asking for passkey]ing in the way

1. The npm CLI is one of the worst CLIs I've ever used. The most essential commands are missing, the existing commands never feel intuitive. 2. No guardrails for publishing a broken package. The bare minimum npm has to do is publint before npm publish. 3. Recent release token changes is a disaster

I've got packages configured identically and some of them publish fine while others throw the infamous 404 meaning 403 meaning something else entirely. 4. Bad error messages (see above). 5. No publish queue and device confirmation, which would be the actual solution to supply chain attacks.

6. Package deprecation in the UI has no way to specify the deprecation reason. That's only possible via the CLI. Deprecation reason cannot be added after the fact for whatever reason (pun intended). Extremely easy to mess up.

The code tab. I wish it was as convenient as browsing files in github, where I can both link to files and also individual lines.

I am still frustrated about them: - Enforcing two factor auth - Disallowing OTP - Not even having atleast something like an Email based two-factor for publishing packages Feels like NPM is trying to solve security issues by just artificially making it hard to publish packages for everyone.

You’re interested in a package author / maintainer PoV here, right?

- as many have said, can't link to code, let alone a line (range) in a file - link to github doesn't respect `repository.directory` from pkg; big waste of time for monorepos - readme doesn't render GitHub Markdown fully - doesn't show pkg's full install size, # of deps, sec warnings...

it was good to re-read this one now :)

hell yeah, we're already at 4/4 here, aren't we?

- No dark mode - No way to link to code in code tab - No way to use OIDC for a first package release - The TS badge doesn’t support modern module resolution - No peer dependencies in the dependencies tab - No distinction between my lifecycle hooks and that of dependencies in CLI

All of these, but peer deps and not being able to link to code are huge ones to me

Another thing that would be great is some mechanism similar to bundlejs.com, as the complete package size is very often completely wrong. Then again, this is a can of worms that is most likely unsolvable, especially for packages with granular, isomorphic, or dynamically loadable resources.

Another one: If a package homepage is a link to the repository, then it’s just silly to render both a link to the repository and to the homepage.

... and done ✅