5 ms·

That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For package

That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node https://deno.land/std@0.80.0/node. It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting better.

nikisweeting 6y ago
Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. 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 & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.
- jimmyspice 6y ago
  why not use artrifactory or similar proxy so you always have a local mirror?
  - nikisweeting 6y ago
    That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.
    - wperron 6y ago
      to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really) The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from
- bartlomieju 6y ago
  > 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.
- Kaido 6y ago
  My understanding is that Deno modules get cached after being used so that you can use it offline.
- deleted 6y ago
  [deleted]
galaxyLogic 6y ago
That is interesting. Does it mean I will be able to run my Node.js program on Deno? That would be really huge in terms of letting users migrate from Node.js to Deno.

nikisweeting 6y ago

Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. 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 & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.

jimmyspice 6y ago
why not use artrifactory or similar proxy so you always have a local mirror?
- nikisweeting 6y ago
  That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.
  - wperron 6y ago
    to be fair, you _should_ probably already be proxying npm and importing from an internal domain (same would be true in any language, really) The truth is, even with a centralized repository, we're still importing user-code, made by humans that may not be well intentioned or simply not know that their code is vulnerable: proxying within your network and running periodic checks against the content of the local cache would be good practice, no where the code came from
bartlomieju 6y ago
> 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.
Kaido 6y ago
My understanding is that Deno modules get cached after being used so that you can use it offline.
deleted 6y ago
[deleted]

galaxyLogic 6y ago

That is interesting. Does it mean I will be able to run my Node.js program on Deno? That would be really huge in terms of letting users migrate from Node.js to Deno.