3 ms·

There are I'm sure valid reasons for doing it, but it fragments an already fragmented ecosystem. And IMHO it is ideal for there to be a first-party solution lik

by wilg 5y ago

There are I'm sure valid reasons for doing it, but it fragments an already fragmented ecosystem. And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler, Rust/Cargo, Swift/SPM, etc.

imbnwa 5y ago
Isn't the first party solution NPM?
- inopinatus 5y ago
  The first-party solution is ES Modules. Node is not Javascript.
  - codetrotter 5y ago
    ES Modules aren't package management though? In that ES Modules say nothing about how to get the modules in the first place, nor anything about versions. Not in any standardized way anyhow.
    - inopinatus 5y ago
      Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Which is to say, yes, it’s painfully half-baked and riddled with inconsistencies. But that is pretty typical of JavaScript anyhow.
      - codetrotter 5y ago
        > Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Yeah but what I mean is that as it stands you literally cannot implement a package manager based on ES Modules alone. So it’s strange to me that someone would say that ES Modules are the package management solution for JavaScript. That’s not what it is currently for. Though the relevant standards may certainly be officially extended in the future, to allow for standardized package management based on ES Modules.
        inopinatus 5y ago
        No, that’s still fixating on the mechanics, not the problem. Package management is not a valuable outcome, it’s a means to an end. In principle, ES modules do away with needing a package manager. And yes, folks are already working on the consequential gaps in capability. The point still being, however incomplete it currently is, this is the first-party solution. Node is not JavaScript.
- mbesto 5y ago
  You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.
- kall 5y ago
  It still ships with node, right? So yeah.
dragonwriter 5y ago
> And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler Bundler, AFAIK, isn't first-party, its a separate team and project. Historically, IIRC, gems wasn't even first-party Good standard solutions are often the outcome of multiple competing efforts pushing forward, proving what works, and proving what doesn't.
- wilg 5y ago
  Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f24517296e6ddf937fdf6bc https://github.com/ruby/ruby/commit/59c8d50653480bef3f245172... But, it's irrelevant. I'm not arguing no one should make a third-party package manager, just that there should be a standard, ideally first-party one, that is good and well supported. Languages like Ruby, Rust, Swift have recognized it is beneficial for the core project to provide a package management solution.

by wilg 5y ago

imbnwa 5y ago

Isn't the first party solution NPM?

inopinatus 5y ago
The first-party solution is ES Modules. Node is not Javascript.
- codetrotter 5y ago
  ES Modules aren't package management though? In that ES Modules say nothing about how to get the modules in the first place, nor anything about versions. Not in any standardized way anyhow.
  - inopinatus 5y ago
    Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Which is to say, yes, it’s painfully half-baked and riddled with inconsistencies. But that is pretty typical of JavaScript anyhow.
    - codetrotter 5y ago
      > Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are. Yeah but what I mean is that as it stands you literally cannot implement a package manager based on ES Modules alone. So it’s strange to me that someone would say that ES Modules are the package management solution for JavaScript. That’s not what it is currently for. Though the relevant standards may certainly be officially extended in the future, to allow for standardized package management based on ES Modules.
      - inopinatus 5y ago
        No, that’s still fixating on the mechanics, not the problem. Package management is not a valuable outcome, it’s a means to an end. In principle, ES modules do away with needing a package manager. And yes, folks are already working on the consequential gaps in capability. The point still being, however incomplete it currently is, this is the first-party solution. Node is not JavaScript.
mbesto 5y ago
You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.
kall 5y ago
It still ships with node, right? So yeah.

dragonwriter 5y ago

> And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler Bundler, AFAIK, isn't first-party, its a separate team and project. Historically, IIRC, gems wasn't even first-party Good standard solutions are often the outcome of multiple competing efforts pushing forward, proving what works, and proving what doesn't.

wilg 5y ago
Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f24517296e6ddf937fdf6bc https://github.com/ruby/ruby/commit/59c8d50653480bef3f245172... But, it's irrelevant. I'm not arguing no one should make a third-party package manager, just that there should be a standard, ideally first-party one, that is good and well supported. Languages like Ruby, Rust, Swift have recognized it is beneficial for the core project to provide a package management solution.