8 ms·

Even PHP gets this right. It's not hard. It makes me wonder why npm hasn't already moved to namespaced package names.

Fellshard 7y ago
Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe, and so seem to reinvent the wheel, rediscover the worst of software's history, and discard the most useful of software findings with shocking regularity. NPM tends to reinforce the worst of the JS world's tendencies.
- geofft 7y ago
  Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.
  - twic 7y ago
    cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.
    - geofft 7y ago
      Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.
      - twic 7y ago
        > Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages. > and reinventing the wheel I didn't mention reinventing the wheel. > I'm not sure what words mean anymore. Agreed, but i'm not sure i can help you with that.
    - kibwen 7y ago
      Namespaces would be a feature of Crates.io, not Cargo (and Crates.io was not contracted to Yehuda Katz, as Cargo was).
      - twic 7y ago
        How so? Do you mean that Cargo would support crates with names like "example/foo" or "org.example/foo", but that's just not how Crates.io works? If so, that's interesting, but then my question is why we didn't make use of that.
        steveklabnik 7y ago
        There's a few different elements of the design space. But, while Cargo can use crates.io, it's distinct from it, so on first principle, this would be a crates.io feature. That being said, Cargo would also have to understand it, because the Rust language does not understand namespaced external packages, so you'd either have to change the language, or change Cargo to do something to paper over that somehow. As for "why didn't we do this in the first place with crates.io", https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... lays out some of this background, though not all of it.
        twic 7y ago
        Thanks for the reference! > When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. I will never stop admiring your ability to see the bright side of things.
    - steveklabnik 7y ago
      Cargo is more like npm than Bundler in this regard, as Bundler does not let you have multiple versions of a package at the same time. That lesson was learned from npm, though implemented in a different way.
  - Fellshard 7y ago
    That is why I cited the behaviour and culture of JavaScript-only devs as the primary explanation, with NPM's model reinforcing those issues - issues that do not exist in the same manner in those other languages' ecosystems and cultures.
  - wdroz 7y ago
    conda use namespaces (called channels). If you want a package from a random person, you've to explicitly add it (either globally or when installing the package).
  - adev_ 7y ago
    > Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does Wrong. None of them have chosen the "micro-package" way of NPM. None of them have an average size of "3-10" line of code per package, which NPM has for many MANY packages. Cargo, pip have many packages but "reasonnable size" packages. ( > 100 lines ). The Micro-package philosophy that NPM chose, meaning every single line of code can have its own package, increase by several factor the number of dependencies required to create anything in JS. A simple hello world in react already have ~100 dependencies https://npm.anvaka.com/#/view/2d/react-create-app https://npm.anvaka.com/#/view/2d/react-create-app Some core utility bundler/packer/etc overpasses 2000 dependencies https://npm.anvaka.com/#/view/2d/webpack https://npm.anvaka.com/#/view/2d/webpack This is madness. It is a simple evidence that bigger the dependency tree is, higher the chance of "one element" malicious / corrupted is. Maybe the NPM developpers / users should reflect on what lead to this situation instead of closing their eyes and sing "everything is fine".
    - m90 7y ago
      > None of them have chosen the "micro-package" way of NPM. This is not something inherent to npm itself, it's what the people using npm choose to publish. No matter if people like small modules or not, it's not at all related to the topic discussed.
      - adev_ 7y ago
        > No matter if people like small modules or not, it's not at all related to the topic discussed. It is very relevant to the topic discussed. Just for fun : https://npm.anvaka.com/#/view/2d/purescript https://npm.anvaka.com/#/view/2d/purescript > 150 dependencies. Including a package named "one-time", bundled several times in two different versions. To do something highly relevant and technical like "Call a function once". I have no doubt that it is an Highly complex code that requires indeed two packages..... Irony Little question: What would have been the probability of purescript getting malicious if its dependency tree would be something reasonnable... Let's say 20 packages instead of the current ~200 ?
        7y ago
- allover 7y ago
  > Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?
  - Fellshard 7y ago
    Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.
    - buzzerbetrayed 7y ago
      So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the > vast majority of JS developers don't seem to be aware of the rest of the software universe Forgive me if I dismiss this as business-as-usual JS bashing
      - Fellshard 7y ago
        There is a difference between arbitrary bashing and giving concrete points of concern. I would hope such criticism would not be dismissed out of hand.
        yawaramin 7y ago
        What concrete points of concern? I don't see any...?
      - hnbroseph 7y ago
        sure, it's just sampling.
  - pjmlp 7y ago
    For starters, developers in other language communities don't publish packages for single line functions.
Ayesh 7y ago
PHP dependency management (composer and packagist) got many things right, such as namespaces packages, lock files, proper autoloading, etc.
preommr 7y ago
They have, its just optional.
allover 7y ago
> Even PHP gets this right. It's not hard. PHP had the luxury of coming out with a package manager (Composer) later, and learning from others before it. (2012 vs 2010 for npm). Npm similarly improved on a lot of package managers that came before (e.g it's superior to Pip, which doesn't resolve dependencies [1]). > It makes me wonder why npm hasn't already moved to namespaced package names. Also, npm does have namespaced package names, the problem is that it was introduced later, so isn't mandatory. I'm not sure how they could make it mandatory without breaking everyone? [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988
- oblio 7y ago
  Apache Maven was released in 2004... PHP just looked at what Java was doing. Might be a wrong idea for some things but it definitely helps for stuff such as package management.
  - deleted 7y ago
    [deleted]

Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe, and so seem to reinvent the wheel, rediscover the worst of software's history, and discard the most useful of software findings with shocking regularity. NPM tends to reinforce the worst of the JS world's tendencies.

geofft 7y ago
Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does, so that doesn't seem to be the explanation here.
- twic 7y ago
  cargo, at least, does this for the reason Fellshard gives - the Rust team essentially commissioned a copy of Ruby's bundler, without considering whether there was anything to learn from any other language's ecosystem.
  - geofft 7y ago
    Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages and reinventing the wheel, I'm not sure what words mean anymore.
    - twic 7y ago
      > Well, okay, if your point of view is that behaving like multiple other major languages and specifically taking the lessons (good and bad) of a specific existing language ecosystem into account before doing your own thing is the same as disregarding other languages If you've only looked at two or three languages that not coincidentally happen to do things pretty much the same as each other, and not looked elsewhere, then you are indeed disregarding other languages. > and reinventing the wheel I didn't mention reinventing the wheel. > I'm not sure what words mean anymore. Agreed, but i'm not sure i can help you with that.
  - kibwen 7y ago
    Namespaces would be a feature of Crates.io, not Cargo (and Crates.io was not contracted to Yehuda Katz, as Cargo was).
    - twic 7y ago
      How so? Do you mean that Cargo would support crates with names like "example/foo" or "org.example/foo", but that's just not how Crates.io works? If so, that's interesting, but then my question is why we didn't make use of that.
      - steveklabnik 7y ago
        There's a few different elements of the design space. But, while Cargo can use crates.io, it's distinct from it, so on first principle, this would be a crates.io feature. That being said, Cargo would also have to understand it, because the Rust language does not understand namespaced external packages, so you'd either have to change the language, or change Cargo to do something to paper over that somehow. As for "why didn't we do this in the first place with crates.io", https://internals.rust-lang.org/t/crates-io-package-policies/1041 https://internals.rust-lang.org/t/crates-io-package-policies... lays out some of this background, though not all of it.
        twic 7y ago
        Thanks for the reference! > When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. I will never stop admiring your ability to see the bright side of things.
  - steveklabnik 7y ago
    Cargo is more like npm than Bundler in this regard, as Bundler does not let you have multiple versions of a package at the same time. That lesson was learned from npm, though implemented in a different way.
- Fellshard 7y ago
  That is why I cited the behaviour and culture of JavaScript-only devs as the primary explanation, with NPM's model reinforcing those issues - issues that do not exist in the same manner in those other languages' ecosystems and cultures.
- wdroz 7y ago
  conda use namespaces (called channels). If you want a package from a random person, you've to explicitly add it (either globally or when installing the package).
- adev_ 7y ago
  > Perl (cpan), Python (pip or conda), Ruby (gem), and Rust (cargo) all behave as NPM does Wrong. None of them have chosen the "micro-package" way of NPM. None of them have an average size of "3-10" line of code per package, which NPM has for many MANY packages. Cargo, pip have many packages but "reasonnable size" packages. ( > 100 lines ). The Micro-package philosophy that NPM chose, meaning every single line of code can have its own package, increase by several factor the number of dependencies required to create anything in JS. A simple hello world in react already have ~100 dependencies https://npm.anvaka.com/#/view/2d/react-create-app https://npm.anvaka.com/#/view/2d/react-create-app Some core utility bundler/packer/etc overpasses 2000 dependencies https://npm.anvaka.com/#/view/2d/webpack https://npm.anvaka.com/#/view/2d/webpack This is madness. It is a simple evidence that bigger the dependency tree is, higher the chance of "one element" malicious / corrupted is. Maybe the NPM developpers / users should reflect on what lead to this situation instead of closing their eyes and sing "everything is fine".
  - m90 7y ago
    > None of them have chosen the "micro-package" way of NPM. This is not something inherent to npm itself, it's what the people using npm choose to publish. No matter if people like small modules or not, it's not at all related to the topic discussed.
    - adev_ 7y ago
      > No matter if people like small modules or not, it's not at all related to the topic discussed. It is very relevant to the topic discussed. Just for fun : https://npm.anvaka.com/#/view/2d/purescript https://npm.anvaka.com/#/view/2d/purescript > 150 dependencies. Including a package named "one-time", bundled several times in two different versions. To do something highly relevant and technical like "Call a function once". I have no doubt that it is an Highly complex code that requires indeed two packages..... Irony Little question: What would have been the probability of purescript getting malicious if its dependency tree would be something reasonnable... Let's say 20 packages instead of the current ~200 ?
      - 7y ago
allover 7y ago
> Mostly because the vast majority of JS developers don't seem to be aware of the rest of the software universe Do you have any evidence to back up this statement, compared to developers in other languages? Or is this just business-as-usual JS bashing?
- Fellshard 7y ago
  Primarily, I end up basing this off of the types of libraries being developed for Javascript, and what kinds of articles and thought leaders JS developers tout as innovative.
  - buzzerbetrayed 7y ago
    So by looking at a tiny fraction of the 1 million+ npm libraries, and articles by a few dozen people on the internet, you are able to conclude that the > vast majority of JS developers don't seem to be aware of the rest of the software universe Forgive me if I dismiss this as business-as-usual JS bashing
    - Fellshard 7y ago
      There is a difference between arbitrary bashing and giving concrete points of concern. I would hope such criticism would not be dismissed out of hand.
      - yawaramin 7y ago
        What concrete points of concern? I don't see any...?
    - hnbroseph 7y ago
      sure, it's just sampling.
- pjmlp 7y ago
  For starters, developers in other language communities don't publish packages for single line functions.

Ayesh 7y ago

PHP dependency management (composer and packagist) got many things right, such as namespaces packages, lock files, proper autoloading, etc.

preommr 7y ago

They have, its just optional.

allover 7y ago

> Even PHP gets this right. It's not hard. PHP had the luxury of coming out with a package manager (Composer) later, and learning from others before it. (2012 vs 2010 for npm). Npm similarly improved on a lot of package managers that came before (e.g it's superior to Pip, which doesn't resolve dependencies [1]). > It makes me wonder why npm hasn't already moved to namespaced package names. Also, npm does have namespaced package names, the problem is that it was introduced later, so isn't mandatory. I'm not sure how they could make it mandatory without breaking everyone? [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988

oblio 7y ago
Apache Maven was released in 2004... PHP just looked at what Java was doing. Might be a wrong idea for some things but it definitely helps for stuff such as package management.
- deleted 7y ago
  [deleted]