10 ms·

This is my first time seeing it but so much of it looks great. I don’t think I’m a fan with how it handles dependencies, though. It feels like they’ve just rein

This is my first time seeing it but so much of it looks great. I don’t think I’m a fan with how it handles dependencies, though. It feels like they’ve just reinvented GOPATH. “Deno caches remote imports in a special directory specified by the $DENO_DIR environmental variable. It default to $HOME/.deno if $DENO_DIR is not specified. ... Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.“ https://github.com/denoland/deno/blob/master/Docs.md https://github.com/denoland/deno/blob/master/Docs.md The suggestion to import and reexport dependencies in a central `package.ts` file sounds absurd to me. Clearly, I’m not a user and am just now reading this for the first time. Has there been discussion about this in the community? Are there plans to correct it? Go has been digging out of this hole for years, I can’t imagine why they’d start in the same place.

bartlomieju 8y ago
Disclaimer: I contribute to Deno. Contrary to Go, when using Deno you don't need to invoke any command to install a package. You just put your import statement with full URL (you can pin version there, eg. https://unpkg.com/liltest@0.0.5/dist/liltest.js https://unpkg.com/liltest@0.0.5/dist/liltest.js) and Deno downloads it on first run and caches for later use. Changing $DENO_DIR is somehow equivalent to changing node_modules location. This eliminates need for package manager.
- mmmeff 8y ago
  I feel that the Deno project's goals to get away from NPM/centralized registries is causing developer experience pains that it feels like you're trying to sweep under the rug. Maybe it's time to take a look at building a replacement package manager. The convenience of having a single package manager that handles name resolution, versioning, governance, and security is why NPM is as prolific as it is today. That being said, the reason NPM even received any traction from the start was because Isaacs bundled it with the Node distribution. In my opinion, this is the clear chance for Deno to provide its own, better package manager, built on top of IPFS/Dat or some similarly decentralized protocol, and correcting the many mistakes that have been openly accepted by Isaacs and others in the lineage of Node/NPM.
  - bartlomieju 8y ago
    I don't have knowledge about early NPM stages, but from my perspective the goal right now is to get rid of need for package manager.
    - mmmeff 8y ago
      How does Deno need a package manager at the moment? I don’t understand your perspective.
      - k__ 8y ago
        I think the point here is, that Node.js needs one and Deno is created to get away from that.
        mmmeff 8y ago
        How exactly does Node.js require a package manager?
        k__ 8y ago
        Well, it doesn't technically require it...
        mmmeff 8y ago
        Exactly. Deno doesn't need to solve for this, it's already achieved it. An interpreter has nothing to do with a package manager. One problem that Deno is actually solving is the tight coupling of NPM and Node. Commonjs is very much purpose-built for NPM modules. It's a smart call for the team to tackle this problem as it's one of the biggest pain points of using Node and the biggest threat to its long-term sustainability. But I fail to see how no package manager is a viable solution. As someone who's used Go and Node for the majority of the time they have existed, trust me when I say that a package manager is a good thing. Node is an incredible ecosystem. We just need a better implementation of its package manager.
- stephen 8y ago
  I'm tempted to apply a Greenspun-ism, that by "not having a package manager", you're going to effectively have a half-implemented, bug-ridden package manager anyway. :-) More seriously, dealing with the version hell that is inherent in dynamically assembling (your project has it's own unique dependency graph) publicly shared, uncontrolled libraries (only Google has a true no-version-numbers-ever monorepo) is nontrivial and so it seems like surely there has to be something being "effectively a dependency manager", though perhaps it is just semantics of embedding that in the runtime "because imports are urls in the source files and not a separate Json file"...not sure what fundamental benefit that brings though?

bartlomieju 8y ago

Disclaimer: I contribute to Deno. Contrary to Go, when using Deno you don't need to invoke any command to install a package. You just put your import statement with full URL (you can pin version there, eg. https://unpkg.com/liltest@0.0.5/dist/liltest.js https://unpkg.com/liltest@0.0.5/dist/liltest.js) and Deno downloads it on first run and caches for later use. Changing $DENO_DIR is somehow equivalent to changing node_modules location. This eliminates need for package manager.

mmmeff 8y ago
I feel that the Deno project's goals to get away from NPM/centralized registries is causing developer experience pains that it feels like you're trying to sweep under the rug. Maybe it's time to take a look at building a replacement package manager. The convenience of having a single package manager that handles name resolution, versioning, governance, and security is why NPM is as prolific as it is today. That being said, the reason NPM even received any traction from the start was because Isaacs bundled it with the Node distribution. In my opinion, this is the clear chance for Deno to provide its own, better package manager, built on top of IPFS/Dat or some similarly decentralized protocol, and correcting the many mistakes that have been openly accepted by Isaacs and others in the lineage of Node/NPM.
- bartlomieju 8y ago
  I don't have knowledge about early NPM stages, but from my perspective the goal right now is to get rid of need for package manager.
  - mmmeff 8y ago
    How does Deno need a package manager at the moment? I don’t understand your perspective.
    - k__ 8y ago
      I think the point here is, that Node.js needs one and Deno is created to get away from that.
      - mmmeff 8y ago
        How exactly does Node.js require a package manager?
        k__ 8y ago
        Well, it doesn't technically require it...
        mmmeff 8y ago
        Exactly. Deno doesn't need to solve for this, it's already achieved it. An interpreter has nothing to do with a package manager. One problem that Deno is actually solving is the tight coupling of NPM and Node. Commonjs is very much purpose-built for NPM modules. It's a smart call for the team to tackle this problem as it's one of the biggest pain points of using Node and the biggest threat to its long-term sustainability. But I fail to see how no package manager is a viable solution. As someone who's used Go and Node for the majority of the time they have existed, trust me when I say that a package manager is a good thing. Node is an incredible ecosystem. We just need a better implementation of its package manager.
stephen 8y ago
I'm tempted to apply a Greenspun-ism, that by "not having a package manager", you're going to effectively have a half-implemented, bug-ridden package manager anyway. :-) More seriously, dealing with the version hell that is inherent in dynamically assembling (your project has it's own unique dependency graph) publicly shared, uncontrolled libraries (only Google has a true no-version-numbers-ever monorepo) is nontrivial and so it seems like surely there has to be something being "effectively a dependency manager", though perhaps it is just semantics of embedding that in the runtime "because imports are urls in the source files and not a separate Json file"...not sure what fundamental benefit that brings though?