4 ms·

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

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.
        johnhenry 8y ago
        const packageManager = require('package-manager'); // QED
        mmmeff 8y ago
        `const npm = require("npm")` actually works AFAIK
- austincheney 8y ago
  You don’t need package management dependency hell just like you don’t need frameworks. This pain is self imposed due to a desire of perceived convenience or the lack of competence to see otherwise. When your total dependency graph is less than 8 packages you can easily manage this manually. This especially true since there are bots that can automatically check for version updates.
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?

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.
      - johnhenry 8y ago
        const packageManager = require('package-manager'); // QED
        mmmeff 8y ago
        `const npm = require("npm")` actually works AFAIK
austincheney 8y ago
You don’t need package management dependency hell just like you don’t need frameworks. This pain is self imposed due to a desire of perceived convenience or the lack of competence to see otherwise. When your total dependency graph is less than 8 packages you can easily manage this manually. This especially true since there are bots that can automatically check for version updates.

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?