6 ms·

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. L

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad

philips 6y ago
I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.
- nikisweeting 6y ago
  I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have left before we hit the HN nesting limit, but this is a thing I care deeply about and I'm down to keep chatting on Twitter or other forums if anyone here prefers)
  - bobthebuilders 6y ago
    I think what Deno is great because it lets me be decentralized. We did so much with open source only to throw it all away with npm and go back to a centralized corporate entity :(
    - hombre_fatal 6y ago
      package.json supports urls, git urls (and branch + commit ids), even local file paths. If you wanted that, what's stopping you?
      - deleted 6y ago
        [deleted]
mark_and_sweep 6y ago
> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager, but an argument for a central package repository. Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.) And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though. In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/ https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...
- nikisweeting 6y ago
  I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.
  - mark_and_sweep 6y ago
    > I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...
    - nikisweeting 6y ago

philips 6y ago

I think that is a strong argument for a community immutable cache like Go uses though. Not a centralized namespace.

nikisweeting 6y ago
I think go is the perfect example of how not to do module source distribution. Because of their URL dependency system Golang projects work great as static binaries, but they're almost impossible to distribute as source builds via system package managers. A lot of my arguments for why this is a bad thing are already laid out here: https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh (I don't know how many more replies we have left before we hit the HN nesting limit, but this is a thing I care deeply about and I'm down to keep chatting on Twitter or other forums if anyone here prefers)
- bobthebuilders 6y ago
  I think what Deno is great because it lets me be decentralized. We did so much with open source only to throw it all away with npm and go back to a centralized corporate entity :(
  - hombre_fatal 6y ago
    package.json supports urls, git urls (and branch + commit ids), even local file paths. If you wanted that, what's stopping you?
    - deleted 6y ago
      [deleted]

mark_and_sweep 6y ago

> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager, but an argument for a central package repository. Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.) And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though. In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/ https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...

nikisweeting 6y ago
I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.
- mark_and_sweep 6y ago
  > I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_maps https://deno.land/manual/linking_to_external_code/import_map...
  - nikisweeting 6y ago