4 ms·

You'd think this would be common sense (Java solved this problem 25 years ago) but apparently some people are extremely opposed to non-flat package namespaces.

You'd think this would be common sense (Java solved this problem 25 years ago) but apparently some people are extremely opposed to non-flat package namespaces. See e.g. Rust, where the idea of hierarchical crate namespaces has been politely but firmly shot down every time it's been requested.

franciscop 5y ago
This is only a problem now that npm has millions and millions of packages, IMHO having a flat structure helps in the beginning (abc/jquery vs def/jquery, which one is the official one?) and having a hierarchical structure helps later on.
- Symbiote 5y ago
  com/jquery. Java 99% solved this decades ago.
- EdwardDiego 5y ago
  On Java it'd be the com.jquery/jquery. As opposed to io.github.randomperson/jquery.
  - Denvercoder9 5y ago
    Not before it became big. Usually projects start out under some random person GitHub page, and only register domain names later on when it gets traction.
    - EdwardDiego 5y ago
      True that, and I've seen packages switch group ids at this point, usually at a major version release. But still makes it easier to verify that you're installing the package you intended. And makes it very hard to deliver typo vulns or squat the "good" names.
    - GauntletWizard 5y ago
      And that's fine. A 1.0 release existing as both randomiser/jQuery and jQuery/jQuery is fine, and then 2.0 only exists as jQuery/jQuery; so long as your package manager has good tooling for rewriting imports (and usually sed is enough). Making migration to alternative implementations easy should already be a design goal.
- mook 5y ago
  The official one of course should be jquery/jquery. Or do it line docker does, and have a reserved official namespace that needs to be whitelisted (that of course has the downside that the people behind the projects don't have direct access and tends to end up with out-of-date packages).
swsieber 5y ago
Java took an approach with one set of trade-offs. Each approach has its pros and cons. > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. I do think Rust will get some form of namespaces, but it'll be quite a bit less powerful than what most proponents of namespaces want. There's been a bit of a disagreement (IIRC) about what a namespace signifies (would signify) in the Rust ecosystem. Edit: I will say, it has been quite the contentious and has been re-hashed ad-naseum. For anyone interested in reliving arguments, search for "namespace" on https://internals.rust-lang.org https://internals.rust-lang.org - There will be a good half-dozen results to read through, though there is a fair bit of re-hashing and talking past each other.

franciscop 5y ago

This is only a problem now that npm has millions and millions of packages, IMHO having a flat structure helps in the beginning (abc/jquery vs def/jquery, which one is the official one?) and having a hierarchical structure helps later on.

Symbiote 5y ago
com/jquery. Java 99% solved this decades ago.
EdwardDiego 5y ago
On Java it'd be the com.jquery/jquery. As opposed to io.github.randomperson/jquery.
- Denvercoder9 5y ago
  Not before it became big. Usually projects start out under some random person GitHub page, and only register domain names later on when it gets traction.
  - EdwardDiego 5y ago
    True that, and I've seen packages switch group ids at this point, usually at a major version release. But still makes it easier to verify that you're installing the package you intended. And makes it very hard to deliver typo vulns or squat the "good" names.
  - GauntletWizard 5y ago
    And that's fine. A 1.0 release existing as both randomiser/jQuery and jQuery/jQuery is fine, and then 2.0 only exists as jQuery/jQuery; so long as your package manager has good tooling for rewriting imports (and usually sed is enough). Making migration to alternative implementations easy should already be a design goal.
mook 5y ago
The official one of course should be jquery/jquery. Or do it line docker does, and have a reserved official namespace that needs to be whitelisted (that of course has the downside that the people behind the projects don't have direct access and tends to end up with out-of-date packages).

swsieber 5y ago

Java took an approach with one set of trade-offs. Each approach has its pros and cons. > It's less difficult (though still far from easy) to handle name squatting on organization/corporate names as qualifiers for packages than to try and prevent name squatting on package names. I do think Rust will get some form of namespaces, but it'll be quite a bit less powerful than what most proponents of namespaces want. There's been a bit of a disagreement (IIRC) about what a namespace signifies (would signify) in the Rust ecosystem. Edit: I will say, it has been quite the contentious and has been re-hashed ad-naseum. For anyone interested in reliving arguments, search for "namespace" on https://internals.rust-lang.org https://internals.rust-lang.org - There will be a good half-dozen results to read through, though there is a fair bit of re-hashing and talking past each other.