Given the fairly shoddy security story with NPM, I genuinely don't understand the hesitation to publish a binary and have a README instruction to curl/wget it into `/usr/local/bin` or `~/.local/bin`. If it's going through NPM that publishing step has to be done already, unless the NPM build is pulling down rust to compile it all as a native extension.

Eventually it'd wangle it's way into homebrew or the unstable branch of another package registry.

But that's me, because I really dislike installing binaries via a language's package manager, because they don't get updated unless I frequently run the upgrade commands for each package manager.

That (security ) is something I also worry about. I'd like to get off npm if only for this reason. It's a hack to get started.

The other thing it gives you is the ability to easily upgrade and uninstall so just a script to copy stuff is not on par.

Thing is… who is regularly running `npm update` or `cargo update` to keep local software up to date?

I wouldn’t, because I might be in a repo and it starts upgrading all my local dependencies, and I’m not gonna add a text editor as a dev dependency. I’ll happily take the binary, or a tar.gz with the binary in it, though.

(Btw I love how it’s following the old DOS aesthetic)

> who is regularly running `npm update` or `cargo update` to keep local software up to date?

I do, religiously, as part of my routine to check for updates.

  n lts && npm uninstall -g corepack && npm update -g && n prune

Sometimes things break (that's how `npm uninstall -g corepack` became a part of my one-liner), but it is easier to update often than to neglect updates for years.

The npm distribution here is just the binary, you run npm install again and it upgrades to the latest binary. That's convenient

I'm in the same boat as a JS/TS developer for years to get used to npm install the recent AI command line tools under global scope, it's really weired. Personally I don't event install front end toolchains global as almost all of them work under project scope.

But I totally get the idea behind this, it's greatly combined with the cargo toolchain and is widely installed than cargo (which by the way npm is much easier to install than cargo with my personal experience), npm handles update nicely, and it can handle multiple arch too. I would still prefer npm install because I have installed a lot recently so it's ok.

Take a look at [topgrade](https://github.com/topgrade-rs/topgrade) which can run all of the package managers for you in one go.

Does it matter? You are apparently contemplating running a third-party binary on your machine anyway. It seems a bit weird to Worry about npm’s security story, which is all about executing arbitrary code.

Anything that uses npm is fundamentally untrustworthy. I would argue that if you make an editor you should write software for people that want to use and write good software, which isn't anyone that unironically uses npm with anything other than distaste.

Many of them may not be Node developers either, and might not have npm installed. Using a dependency management tool for one language to distribute a packaged application written in an entirely different language seems like a very strange choice.

Why not use the various standard and commonplace packaging and distribution methods for application software? Distro repos, tarballs, Homebrew, AppImage, Flatpak, etc.

npm is certainly not something everyone has.

Not everyone it's a web developer. Sysadmin and system programmers (and older millenials) don't care and don't want to install anything related to NPM.

I am certainly one of the cane-waving "older millenials".

Friends don't let friends install npm

It is something some of us avoid.

but you could also say a lot of users are web developers and won't have npm installed