4 ms·

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

by vog 9y ago

Klathmon 9y ago
I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? does it change to `@OtherUser/coolThing` or does it stay under `@Klathmon/coolThing` forever? I wouldn't like that second one.) What I would like to see is all new unscoped packages being able to be installed/required by their scoped version by default. So if I create a package `coolThing` in npm entirely unscoped, it would be installable by doing `npm -i @Klathmon/coolThing` and by doing `npm -i coolThing` That would let many of us to use the benefits of scoped packages without the package authors having to do anything. And it would be a big step toward going completely scoped at some point in the future.
- kuschku 9y ago
  All the other package managers have solved that. Docker and go use URLs/paths for scoping, everything is scoped. Java/Scala/Kotlin/XText/etc use reversed domains as scope. And so on.
  - Klathmon 9y ago
    Yes, but many of them started that way, they didn't have to go through the headache of transferring to that format. And even ecosystems that did go through that trouble, they weren't nearly at the scale that npm is. We can talk about how awful of an idea it was for npm to start the way they did all we want, but the reality is that they are in the position of unscoped packages being the "default" right now, and I'd love for them to get away from them in a safe manner.
- DanHulton 9y ago
  All new packages must be scoped. Existing packages can - and shoudl - be aliased by the owner to a scoped package. Everyone's existing code continues to work, while all new code is safe. Doesn't seem especially tricky.
  - Klathmon 9y ago
    I agree, but I'm just guessing. I have a feeling that if there weren't any downsides, it would have been done by now.
    - vog 9y ago
      My feeling ist that the downside basically boils down to: Lots of work, and having to find volunteers implementing that.
lhorie 9y ago
Would it though? I've noticed a trend of libs being created under orgs of the same name, e.g. - https://github.com/angular/angular https://github.com/angular/angular - https://github.com/rollup/rollup https://github.com/rollup/rollup - https://github.com/cherow/cherow https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?
- abjorn 9y ago
  Is that such a bad thing? Slightly redundant, but that seems more aesthetic than anything.
- Klathmon 9y ago
  It does at least partially solve the problem of "typosquatting" where installing `anglar` could potentially be a malicious version. It makes it more obvious when it's happening (oh, you setup the `anglar` and created a ton of typo'd packages with a few lines changed each? That's probably safe to ban...) It also allows those orgs to group "sibling" or sub-packages under their main name. So I know that `@angular/cool-angular-plugin` is actually from angular.
  - lhorie 9y ago
    I get the benefits of namespacing. I'm just not sure making it mandatory solves any issues. For example, what's stopping someone from publishing `@developit/greenlet` or `@greenlet/greenlet` without owning the respective org/username in github?
    - Klathmon 9y ago
      Nothing is stopping that. But for the downside of "having to type a little bit more", I think it's more than useful enough at what it does fix/solve. In other words, it solves between 0 and "a bunch" of problems for packages, and the downside is fixed at "needs to type a little more". Even in the worst case, it's not that much harm, but in the best case could prevent exploits.
- 9y ago
jrochkind1 9y ago
On github, if I expect an open source thing to get some use, I usually put it in an 'organization', instead of my personal github account. To allow it to later be transitioned to a team, or another maintainer, without disruption. If one does the same on npm, it just transfers the namespace scarcity to 'scopes' themselves, with no real benefit.

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

by vog 9y ago

Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...

I don't know of any offical docs or anything, but I'd imagine it's because it would be a pretty big breaking change. (before babel moved to scoped packages, it would be jarring to see `babel-core` unscoped, but `@babel/babel-plugin-thing` as scoped because it was forced. I also think there is still some roughness around "transferring" scoped packages (what happens when another user takes over a package I authored? does it change to `@OtherUser/coolThing` or does it stay under `@Klathmon/coolThing` forever? I wouldn't like that second one.) What I would like to see is all new unscoped packages being able to be installed/required by their scoped version by default. So if I create a package `coolThing` in npm entirely unscoped, it would be installable by doing `npm -i @Klathmon/coolThing` and by doing `npm -i coolThing` That would let many of us to use the benefits of scoped packages without the package authors having to do anything. And it would be a big step toward going completely scoped at some point in the future.

kuschku 9y ago
All the other package managers have solved that. Docker and go use URLs/paths for scoping, everything is scoped. Java/Scala/Kotlin/XText/etc use reversed domains as scope. And so on.
- Klathmon 9y ago
  Yes, but many of them started that way, they didn't have to go through the headache of transferring to that format. And even ecosystems that did go through that trouble, they weren't nearly at the scale that npm is. We can talk about how awful of an idea it was for npm to start the way they did all we want, but the reality is that they are in the position of unscoped packages being the "default" right now, and I'd love for them to get away from them in a safe manner.
DanHulton 9y ago
All new packages must be scoped. Existing packages can - and shoudl - be aliased by the owner to a scoped package. Everyone's existing code continues to work, while all new code is safe. Doesn't seem especially tricky.
- Klathmon 9y ago
  I agree, but I'm just guessing. I have a feeling that if there weren't any downsides, it would have been done by now.
  - vog 9y ago
    My feeling ist that the downside basically boils down to: Lots of work, and having to find volunteers implementing that.

lhorie 9y ago

Would it though? I've noticed a trend of libs being created under orgs of the same name, e.g. - https://github.com/angular/angular https://github.com/angular/angular - https://github.com/rollup/rollup https://github.com/rollup/rollup - https://github.com/cherow/cherow https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?

abjorn 9y ago
Is that such a bad thing? Slightly redundant, but that seems more aesthetic than anything.
Klathmon 9y ago
It does at least partially solve the problem of "typosquatting" where installing `anglar` could potentially be a malicious version. It makes it more obvious when it's happening (oh, you setup the `anglar` and created a ton of typo'd packages with a few lines changed each? That's probably safe to ban...) It also allows those orgs to group "sibling" or sub-packages under their main name. So I know that `@angular/cool-angular-plugin` is actually from angular.
- lhorie 9y ago
  I get the benefits of namespacing. I'm just not sure making it mandatory solves any issues. For example, what's stopping someone from publishing `@developit/greenlet` or `@greenlet/greenlet` without owning the respective org/username in github?
  - Klathmon 9y ago
    Nothing is stopping that. But for the downside of "having to type a little bit more", I think it's more than useful enough at what it does fix/solve. In other words, it solves between 0 and "a bunch" of problems for packages, and the downside is fixed at "needs to type a little more". Even in the worst case, it's not that much harm, but in the best case could prevent exploits.
9y ago

jrochkind1 9y ago

On github, if I expect an open source thing to get some use, I usually put it in an 'organization', instead of my personal github account. To allow it to later be transitioned to a team, or another maintainer, without disruption. If one does the same on npm, it just transfers the namespace scarcity to 'scopes' themselves, with no real benefit.