6 ms·

> We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, b

> We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with a path you can tell Deno to change that cache dir. And these files are cached indefinitely; Deno will not try to fetch them again on next run (unless you opt into it with --reload flag).

nikisweeting 6y ago
Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.
- bartlomieju 6y ago
  There's nothing preventing you from still using a central repository (or its mirrors). I highly recommend "Deno is a Browser for Code" by Kitson [1] which discusses this subject in more depth. [1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/ https://kitsonkelly.com/posts/deno-is-a-browser-for-code/
  - nikisweeting 6y ago
    Hmm I don't find this article very convincing. From my perspective this is a security and sysadmin nightmare (for the reasons in my link above). Lockfiles actually provide repeatable builds almost all the time, the only times they fail are when depending on non-JS builds like node-gyp or other C++/etc dependencies where you can't lock on system build tooling versions because they're outside the scope of what npm can lock. The real appeal of Deno for our org is the stdlib, which as a side effect means we can depend on fewer packages. The wholesale removal of the package manager seems like an unwanted pain that will only keep us away from switching and gaining the stdlib benefits.
    - 14u2c 6y ago
      You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash: deno run --allow-write=~/.myapp https://myapp.io/install.ts https://myapp.io/install.ts It works quite well as secure scripting runtime.
      - nikisweeting 6y ago
        I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem. It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well). I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.
        rewq4321 6y ago
        > It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement The 1.0 announcement post the team mentioned: > For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno. and: > Over time, we expect Deno to be able to run more and more Node programs out-of-the-box. I don't think they've ever claimed to be an immediate drop-in replacement.
        mark_and_sweep 6y ago
        Here's a quick example of how to use import maps to get Node-like imports for ES modules distributed on NPM like lodash-es: https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1decfac60dcb2d https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1dec...
- mark_and_sweep 6y ago
  > Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.
  - nikisweeting 6y ago
    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 :(
- jay_kyburz 6y ago
  I would probably just vendor them into my own directory structure and import them as a local module. You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.
  - nikisweeting 6y ago
    Vendoring is a last resort, that sounds like going back to the stone ages of package management. Why would I want that?
    - jay_kyburz 6y ago
      I think the advantages far outweigh the downsides. I don't really care how old the idea is.
  - vorticalbox 6y ago
    >You lose automatic updating, but I'm not sure I want that anyhow. I'm getting on this boat after mongoose changed its type definitions and ruined a whole morning of work for me.
- wperron 6y ago
  The beauty of Deno is that it's agnostic about where you import your code; At the moment deno.land/x only allows tags to be published - no semver range resolution, and doesn't allow versions to be removed/update. nest.land is another popular one, and is build on top of the arweave blockchain, bringing that chain of trust you mention. The ecosystem is still in evolution but I expect that it stabilize around a few generic registries for smaller libs, and larger libs hosting their code themselves in the long run. The point is; while URLs _can_ be very loosy goosy ways to address code, they can also be made very strict - it will depend on the actual server behind it. As a side note, npm is already pretty poor at providing those guarantees anyway, I find it interesting that it's usually assumed to be a safe way to install dependencies.

nikisweeting 6y ago

Local caching alone loses all the benefits of using a package manager though. I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh https://docs.monadical.com/s/against-curl-sh Using URLs means there are no rules enforced, the code hosted at that URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.

bartlomieju 6y ago
There's nothing preventing you from still using a central repository (or its mirrors). I highly recommend "Deno is a Browser for Code" by Kitson [1] which discusses this subject in more depth. [1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/ https://kitsonkelly.com/posts/deno-is-a-browser-for-code/
- nikisweeting 6y ago
  Hmm I don't find this article very convincing. From my perspective this is a security and sysadmin nightmare (for the reasons in my link above). Lockfiles actually provide repeatable builds almost all the time, the only times they fail are when depending on non-JS builds like node-gyp or other C++/etc dependencies where you can't lock on system build tooling versions because they're outside the scope of what npm can lock. The real appeal of Deno for our org is the stdlib, which as a side effect means we can depend on fewer packages. The wholesale removal of the package manager seems like an unwanted pain that will only keep us away from switching and gaining the stdlib benefits.
  - 14u2c 6y ago
    You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash: deno run --allow-write=~/.myapp https://myapp.io/install.ts https://myapp.io/install.ts It works quite well as secure scripting runtime.
    - nikisweeting 6y ago
      I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem. It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well). I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.
      - rewq4321 6y ago
        > It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement The 1.0 announcement post the team mentioned: > For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno. and: > Over time, we expect Deno to be able to run more and more Node programs out-of-the-box. I don't think they've ever claimed to be an immediate drop-in replacement.
      - mark_and_sweep 6y ago
        Here's a quick example of how to use import maps to get Node-like imports for ES modules distributed on NPM like lodash-es: https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1decfac60dcb2d https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1dec...
mark_and_sweep 6y ago
> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.
- nikisweeting 6y ago
  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 :(
jay_kyburz 6y ago
I would probably just vendor them into my own directory structure and import them as a local module. You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.
- nikisweeting 6y ago
  Vendoring is a last resort, that sounds like going back to the stone ages of package management. Why would I want that?
  - jay_kyburz 6y ago
    I think the advantages far outweigh the downsides. I don't really care how old the idea is.
- vorticalbox 6y ago
  >You lose automatic updating, but I'm not sure I want that anyhow. I'm getting on this boat after mongoose changed its type definitions and ruined a whole morning of work for me.
wperron 6y ago
The beauty of Deno is that it's agnostic about where you import your code; At the moment deno.land/x only allows tags to be published - no semver range resolution, and doesn't allow versions to be removed/update. nest.land is another popular one, and is build on top of the arweave blockchain, bringing that chain of trust you mention. The ecosystem is still in evolution but I expect that it stabilize around a few generic registries for smaller libs, and larger libs hosting their code themselves in the long run. The point is; while URLs _can_ be very loosy goosy ways to address code, they can also be made very strict - it will depend on the actual server behind it. As a side note, npm is already pretty poor at providing those guarantees anyway, I find it interesting that it's usually assumed to be a safe way to install dependencies.