6 ms·

Deno still won't have a package manager, at least in the style of npm. You don't need to learn a bunch of CLI and janitor a package.json file. You just add an

Deno still won't have a package manager, at least in the style of npm. You don't need to learn a bunch of CLI and janitor a package.json file. You just add an import to your source code and you're done. Pulling in a npm package is the same as pulling in code from github, it's just a special URL. That's it... that's the 'package manager'.

hardwaregeek 4y ago
I wouldn't bet against a regular package manager existing in the near future. We've seen this story with Go :P
- yencabulator 4y ago
  I'd still say Go doesn't have a "package manager". The dependencies are fetched, cached & built as you need it, but there's nothing comparable to "npm i"/"npm uninstall", dpkg/rpm/apk/etc, as such. If you want, you can just import example.com/foo/bar in your source, and the rest is just reproducability (version & hash) and caches.
SomeCallMeTim 4y ago
Except that, as the ecosystem grows, you eventually have packages that are complex enough that they have imports, and those packages have imports. And now because you've hard-coded imports at every level, you can end up with a dozen different versions of the same import, causing potential conflicts between the various components of your app. Package managers evolved to be the way they are _because they're useful._ It's not like people said "let's add all of this complexity for fun!" Direct imports failed as a solution for Go, and they already have been acknowledged as an incomplete solution for Deno (import maps are already a larval form of package.json, but without the ability to inherit child import maps, which means it's still broken, but presumably it will eventually be fixed). Not having a standardized place where you can see the dependencies of a project, and not being able to distinguish which are _development_ vs _runtime_ dependencies, is also rather broken, and would require a package analysis tool that's far more complex than a package manager to use to trace the dependency tree reliably.
- qbasic_forever 4y ago
  Deno has a dependency inspector: https://deno.land/manual/tools/dependency_inspector https://deno.land/manual/tools/dependency_inspector Deno has a concept of locking dependencies to specific versions with a lock file: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_... Its the same stuff npm does but it doesn't depend on npm's CLI. It sounds like you're mad they're moving the cheese a bit. IMHO I'm glad to be rid of the npm ecosystem baggage.
  - cantSpellSober 4y ago
    From Integrity checking > Deno can store and check subresource integrity for modules using a small JSON file Isn't this also "a larval form of package.json" as the parent suggested? (I want to learn about Deno)
    - qbasic_forever 4y ago
      Package.json is a mish mash of a lot of concerns. It has project metadata, that's also duplicated in your readme and github descriptions. It has scripts, that are also probably just calling into other shell scripts and such in your project. It has your dependencies. It has your development environment setup. It has random key value pairs you decided to place there years ago and forgot the exact reason for now but are too scared to remove them. It's a royal mess of a file to manage. Having a file to manage locked dependency versions isn't bad. Having a file that has grown into a crufty monster with millions of uses can be bad.
      - SomeCallMeTim 4y ago
        I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project. In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file. Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding. Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem. [1] https://www.npmjs.com/package/license-checker https://www.npmjs.com/package/license-checker [2] https://www.npmjs.com/package/husky https://www.npmjs.com/package/husky

hardwaregeek 4y ago

I wouldn't bet against a regular package manager existing in the near future. We've seen this story with Go :P

yencabulator 4y ago
I'd still say Go doesn't have a "package manager". The dependencies are fetched, cached & built as you need it, but there's nothing comparable to "npm i"/"npm uninstall", dpkg/rpm/apk/etc, as such. If you want, you can just import example.com/foo/bar in your source, and the rest is just reproducability (version & hash) and caches.

SomeCallMeTim 4y ago

Except that, as the ecosystem grows, you eventually have packages that are complex enough that they have imports, and those packages have imports. And now because you've hard-coded imports at every level, you can end up with a dozen different versions of the same import, causing potential conflicts between the various components of your app. Package managers evolved to be the way they are _because they're useful._ It's not like people said "let's add all of this complexity for fun!" Direct imports failed as a solution for Go, and they already have been acknowledged as an incomplete solution for Deno (import maps are already a larval form of package.json, but without the ability to inherit child import maps, which means it's still broken, but presumably it will eventually be fixed). Not having a standardized place where you can see the dependencies of a project, and not being able to distinguish which are _development_ vs _runtime_ dependencies, is also rather broken, and would require a package analysis tool that's far more complex than a package manager to use to trace the dependency tree reliably.

qbasic_forever 4y ago
Deno has a dependency inspector: https://deno.land/manual/tools/dependency_inspector https://deno.land/manual/tools/dependency_inspector Deno has a concept of locking dependencies to specific versions with a lock file: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_... Its the same stuff npm does but it doesn't depend on npm's CLI. It sounds like you're mad they're moving the cheese a bit. IMHO I'm glad to be rid of the npm ecosystem baggage.
- cantSpellSober 4y ago
  From Integrity checking > Deno can store and check subresource integrity for modules using a small JSON file Isn't this also "a larval form of package.json" as the parent suggested? (I want to learn about Deno)
  - qbasic_forever 4y ago
    Package.json is a mish mash of a lot of concerns. It has project metadata, that's also duplicated in your readme and github descriptions. It has scripts, that are also probably just calling into other shell scripts and such in your project. It has your dependencies. It has your development environment setup. It has random key value pairs you decided to place there years ago and forgot the exact reason for now but are too scared to remove them. It's a royal mess of a file to manage. Having a file to manage locked dependency versions isn't bad. Having a file that has grown into a crufty monster with millions of uses can be bad.
    - SomeCallMeTim 4y ago
      I don't care whether it's all in one file or in a dozen files, but I want all of that information to be available programmatically in a text file (unlike in a readme or on Github) in a standardized location in a project. In that respect, package.json is a strict win. Your lack of willingness to use `git blame` to see why you added a line, or lack of reasonable git comments, is not to be blamed on the file. Complexity is unavoidable. How could you write a tool like license-checker [1] for a Go-based project without having license information in a standardized location? Without the scripts section, how can you create a tool like husky [2] that automatically installs git hooks for a project? Every single part of package.json is there for a good reason; at best you could argue that putting some of it in other files would be aesthetically superior, but that's just bikeshedding. Complexity isn't de facto bad. Some complexity is required if you want a certain level of functionality to become available. Deno (and Go) are slowly accumulating that "cruft" as people realize that those functions are actually useful or even critical to a mature ecosystem. [1] https://www.npmjs.com/package/license-checker https://www.npmjs.com/package/license-checker [2] https://www.npmjs.com/package/husky https://www.npmjs.com/package/husky