1. 11
  1.  

  2. 3

    Great article. Very detailed and informative. Thanks for writing and posting it.

    It doesn’t necessarily need to be a Rust package as well, you can package anything and do anything when the package is installed/executed. That’s why NPM is so dangerous! - a topic for another blog post.

    I’m looking forward to this follow-up article as well, if you’ve got the time and energy to write it. I’ve always felt that there is far too much criticism of the proliferation of tiny, sometimes trivial libraries on npm and not enough criticism of this much more substantial problem that affects security and reliability. So many npm packages these days seem to be compiling a frightening amount of C with neither warning nor consent, often unsuccessfully.

    I haven’t found much discussion of what a better solution might look like. I know it’s a hard problem. When Deno got started, their solution was to give up on package management altogether, importing everything directly by URL before reversing course and adding npm support in November.

    1. 2

      When Deno got started, their solution was to give up on package management altogether, importing everything directly by URL before reversing course and adding npm support in November.

      TBH, I feel the deno way is the solution. url imports + import maps + integrity checks do feel like a sound and minimal approach to code sharing (if you want registries, you can totally import from https://my-registry/whatever). Absence of any kind of build hook for dependencies solves the problem of packages doing stupid (or, really, any) things on install. Capability-based security solves the problem of random scripts stealing your secrets.

      Deno added npm support not because they need a real package management and npm is a pinnacle of that. They added npm support because of course you want to make migration from node as easy as possible. If you stick to deno-only subset of the ecosystem, urls + import maps + lockfiles is how you do deps.

    2. 1

      Possible values are ‘aix’, ‘darwin’, ‘freebsd’,‘linux’, ‘openbsd’, ‘sunos’, and ‘win32’.

      There’s also android, as used in Termux. If you want to build packages for it (which would be nice because compiling it all on device with cargo takes a while), android-arm should map to armv7-linux-androideabi, and i assume android-arm64 maps to arm64-linux-androideabi but i’m not sure.