Scoped or non-scoped package name?

[toverux]

Since it will probably end up being an official React integration, would you like to name it @sweetalert2/react-content? I see it's already published, but it's not too late to change it.

Or better, @sweetalert2/react or something like that, in the case you add more features.

[zenflow]

Since it will probably end up being an official React integration, would you like to name it @sweetalert2/react-content? I see it's already published, but it's not too late to change it.

What would be the point of changing it? Our core package isn't scoped under @sweetalert2/, and neither is our second biggest package @toverux/ngsweetalert2

Or better, @sweetalert2/react or something like that, in the case you add more features

Just as an FYI, I don't see any reason to add more features. This module does One Thing Well. With the ongoing work on extensiblity it should be easy to layer features on top. This module is almost "complete".

[toverux]

What would be the point of changing it?

I like scoped packages because they avoid name collisions and show that a package belongs to an organization (otherwise it looks third-party).

Name collisions aren't a trivial issue, I already had pain finding a free name and I'm tired of all the abandoned and poor packages that are polluting the global namespace and are named after very common words. Unscoped packages are like using window. in JavaScript :smile: It makes searching packages harder too: there are a lot of different packages that are named the same... with the order of two words inverted. Or with more hyphens. Just because the name was already taken.

The core package is not renamed because it is the core package and because changing its name would annoy thousands of users, and people that aren't aware of the change won't receive updates anymore.

However, even the Babel team started to re-scope all of their packages under @babel/ (as aliases, old packages are still updated but not recommended). With 13 millions downloads per month, I don't think they would do that if it wasn't seen as a new good practice, and a way to recognize/search official packages between hundreds of third-party packages.

Also, ngx-sweetalert2 is much, much older than the organization and I already changed its name once before, loosing download history and probably bothering a few users with my deprecation message. I haven't kept @toverux/ for fame, at the contrary I would rescope it to @sweetalert2/ right now if that would not have negative consequences. For reference: https://github.com/sweetalert2/sweetalert2/issues/798#issuecomment-355541106

[zenflow]

Name collisions aren't a trivial issue, I already had pain finding a free name and I'm tired of all the abandoned and poor packages that are polluting the global namespace and are named after very common words. Unscoped packages are like using window. in JavaScript 😄 It makes searching packages harder too: there are a lot of different packages that are named the same... with the order of two words inverted. Or with more hyphens. Just because the name was already taken.

I'm not worried about name collisions (for other packages; I have the name I want for this package) .. If the name I want is taken, I can just be more descriptive or get more creative (package names don't need to be descriptive, e.g. I think sweetalert2-mango would be an acceptable package name) or if you really want that exact package name and you think it's better off with you than staying with the current owner, npm gives you recourse with that. (btw, I can't find the reference but I read from the NPM CTO that they no longer allow you to create packages that just add hyphens to an existing package name).

As for searching:

1. "keywords" in package.json (for the past 1-2 years, npm uses the search algorithm from npms.io which is much better)
2. README.md in core repo

The core package is not renamed because it is the core package and because changing its name would annoy thousands of users, and people that aren't aware of the change won't receive updates anymore.

I understand

show that a package belongs to an organization (otherwise it looks third-party).

I disagree. Experience has taught us all that unscoped packages can belong to an organization. The owner on Github is a more accurate indicator of this, and also has the advantage that it allows the ownership to be changed (i.e. someone external to our org can create a package and then later transfer it to the org without problems).

And since our major packages are not scoped under @sweetalert2 I think scoping this package would actually make it look like this package belongs to different owners.

However, even the Babel team started to re-scope all of their packages under @babel/ (as aliases, old packages are still updated but not recommended). With 13 millions downloads per month, I don't think they would do that if it wasn't seen as a new good practice, and a way to recognize/search official packages between hundreds of third-party packages.

Babel is doing this to indicate the packages that live together in their monorepo, not to indicate the packages that belong to their org. For example, babel-loader belongs to their org but isn't part of the monorepo, so it's published as simply babel-loader. Also, not totally relevant, but I believe you're recommended to use the scoped packages for Babel 7 and the old unscoped packages for Babel 6? Not positive on this, but that would alleviate 99% of the pain of switching. This gives me an idea...

[zenflow]

I would only want to scope this package if sweetalert2 and @toverux/ngsweetalert2 were under the same scope.

I don't know if I want these packages re-scoped (leaning towards no) but it is possible...

The above mentioned idea: We could make it a (relatively simple) breaking change in the next major release. We could publish sweetalert2@8.0.0 without the actual library, just an error message saying you must change the package name to upgrade to version 8. It shouldn't cause much pain because users already have to consciously upgrade to get to the next major, and it would only take a couple of seconds to update the package name in their package.json.

[zenflow]

/cc @limonte

[limonte]

I don't have any strong opinion here. Both of you listed valid arguments. If I'd be forced to vote, my vote would go to the current one - sweetalert2-react-content. I know that some devs are doing this:

PS. could both of you please add the same set of collaborators as on https://www.npmjs.com/package/sweetalert2 to your npm packages so people will be able to inherit the project in case of the author is :skull: (apologies to remind that, but it's how it is with human beings)

[toverux]

I can just be more descriptive or get more creative

The npm ecosystem is full of packages that have a very similar name, or that are using very common english names. Also, sometimes people fork unmaitained packages just to fix a few things or add a feature are re-publish it on npm, but using a different, often similar, name (while they could scope it to their username). The registry's top level is a total mess. What will it look like in ten years if people don't change their habits?

npm gives you recourse with that.

So it creates problems :D

I disagree. Experience has taught us all that unscoped packages can belong to an organization.

Yes, but only because npm organizations are a very recent thing.

Babel is doing this to indicate the packages that live together in their monorepo, not to indicate the packages that belong to their org.

I don't think so. They didn't actually need to create the new packages ("aliases"). The monorepo just probably helps when publishing the two packages (the scoped and the unscoped one), and that's probably what they only did it here. For now.

---

I'm sorry this debate has turned into bikeshedding, when posting the issue, I didn't even thought this could be debated, as there's a general trend in the community to move to scoped names, and scoped packages were a long-awaited feature.

I really think that global names were a design flaw in npm and that they should have never been permitted. That is the case in lots of package manager I've seen. With Composer (a formidable package manager), everything was username/packagename and that was much more predictable. 95% of the time, the fully-qualified github repo name was matching the actual package name.

[toverux]

A last example. How should I have named @toverux/ngx-sweetalert2 according to you? There were already many packages with the combination of "ng", "ngx", "sweet", "alert" and "2". How could I be more descriptive in my package name here? And sometimes, I like original names too but here, it just doesn't makes sense and would decrease the packages' visibility.

With @toverux/, I am actually more descriptive. It's @toverux's implementation of a SweetAlert2 integration. I have the name I want and I'm not polluting the registry.

Oh, and https://www.npmjs.com/package/ngx-sweetalert2 is taken. It's not a very useful integration (according to me, yes, but still) and is outdated. What gives this package author the right to block the name, forever? npm's bad design, from the registry to the CLI.

[limonte]

I just opened https://github.com/trending/js and just one of them has a scoped name - https://github.com/rematch/rematch

vue, react, webpack - no scopes at all or scoped on random packages (@vue/cli but vuex)

@toverux you mentioned Composer, but Ruby and Python doing just well without scopes.

I agree with @toverux's arguments, but

• ecosystems of other (less popular, but more respectful) programming languages are just fine w/o scoped names
• in the JS ecosystem, respectful companies like react or airbnb don't use scopes https://github.com/airbnb/rheostat

So, @zenflow I still don't have any strong opinion, can't help you with making a decision :)

[toverux]

I see that we're approaching 1.0 so I'll close this as the name isn't about to change :) It's not a big deal. But my only regret is that this choice is definitive-ish: it won't be easy to change after that, and I don't see the drawbacks of scoped names, at the contrary.

I still think I'll find some way to publish my package on @sweetalert2/ at some point, as well as any other new SA2-related package I create.

PS. could both of you please add the same set of collaborators as on https://www.npmjs.com/package/sweetalert2 to your npm packages so people will be able to inherit the project in case of the author is :skull:

I think an organization will help on that :) Would you like to create it? After all, we all see the benefits of GitHub organizations. It's not much different with npm to me.

[limonte]

I think an organization will help on that :) Would you like to create it?

Nice idea, done! https://www.npmjs.com/org/sweetalert2

@toverux please do

npm access grant read-write sweetalert2:developers @toverux/ngx-sweetalert2

@zenflow please do

npm access grant read-write sweetalert2:developers sweetalert2-react-content

[zenflow]

Reopening since this package is almost definitely getting renamed.

We are discussing elsewhere what the name should be.

Let's keep the "scoped vs non-scoped package name" aspect of that discussion isolated here.

I don't have time to comment at the moment, but I will soon.

[limonte]

Another example of misusing scoping is Polymer which is using the @polymer/ scope for the

• core repository https://github.com/Polymer/polymer/blob/master/package.json#L2
• polymer-decorators: https://github.com/Polymer/polymer-decorators/blob/master/package.json
• gen-typescript-declarations: https://github.com/Polymer/gen-typescript-declarations/blob/master/package.json

I don't understand the logic why 3 packages mentioned above have the scope and all others don't, e.g.

• https://github.com/Polymer/polymer-analyzer/blob/master/package.json
• https://github.com/Polymer/polymer-build/blob/master/package.json
• https://github.com/Polymer/polymer-cli/blob/master/package.json

https://www.npmjs.com/~polymer

---

The same with Angular:

• https://github.com/angular/angular-cli/blob/master/package.json
• https://github.com/angular/service-worker-builds/blob/master/package.json
• https://github.com/angular/upgrade-builds/blob/master/package.json

but

• https://github.com/angular/material2/blob/master/package.json
• https://github.com/angular/flex-layout/blob/master/package.json

@toverux is there any logic in applying the @angular/ scope to packages in the angular org? If so, could you please clarify that, because I can't see it:

https://www.npmjs.com/~angular

PS polymer and angular aren't organizations but just regular npm users. I would like to see their developers sharing passwords from those npm accounts between each other :D Come on, Google, you don't need to be so dummy.

[zenflow]

A last example. How should I have named @toverux/ngx-sweetalert2 according to you?

sweetalert2-angular isn't taken 😉

My main disagreement is that a scoped name helps to identify the package as official. IMO that is already as plain as day by the fact that it's on the sweetalert2 org on github. Yes, the owner being in the name makes it a more descriptive name, but I that is too much detail for a name, and sometimes that can be an actual problem, when that detail may change.

My main problem with changing it to be a scoped name before releasing 1.0.0 (i.e. before it was too late) was that it suggests that other official packages should also be under the same namespace. This would cause trouble when we want to move a package from the wild into our org. Github repositories can be easily moved to an organization, but npm packages cannot. Sorry that I'm just now communicating this.

Anyways, the ship has sailed long ago for changing it, so I'll close this issue