Comment by ljm

7 days ago

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.

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.