Reserve scopes in npm, like babel.
Closed this issue · 10 comments
Subject of the feature
Reserve scopes in npm, like babel.
Problem
Currently, unifiedjs uses global name scope like remark-* but every developer can reserve such name.
Expected behavior
Nowadays, babel start to use the scope babel for their official plugins like @babel/*. We can be free from name duplication problem if we reserve such scopes, unified, remark, etc
Alternatives
No
I like not having a scope: it removes a form of hierarchy: without scopes, anyone can publish a plugin, and have it be just as official as plugins maintained in the remark org.
/cc @Rokt33r @ChristianMurphy maybe you two have ideas on this too
Two ways of answering this:
Does unified/remark have the namespace reserved on npm and github to prevent name/typo squatters?
Yes, on both NPM and Github use organizations to manage namespaces, and the collective has unified, remarkjs, rehypejs, retextjs, etc setup.
Those orgs are actively used for managing repos, packages, and permissions on both platforms.
Should unified migrate all the repos to use namespaces? Maybe, Maybe not
Name spaces have several advantages
- they prevent name conflicts with other packages on the registry (this isn't a problem we've had without namespacing)
- They allow shorthand installs (E.G.
@babel/{core,cli}installs@babel/coreand@babel/cli - They allow for private packages (unified doesn't have any)
Switching would come at a cost:
- Every package.json would need to be updated with the new name (300+ packages in the collective alone)
- Every adopter would need to update their package.json and all their imports
Is the advantage (shorthand for installs) worth the trade off (changing package.json and imports across lots of packages)?
I'd lean no.
They allow shorthand installs (E.G. @babel/{core,cli} installs @babel/core and @babel/cli
No, it is not feature of npm. It is provided by bash/zsh. The curly brackets would be expanded. For example,
❯ echo @babel/{cli,core}
@babel/cli @babel/coreThus, you can achieve the same behavior with current naming rule.
❯ echo rehype-{mathjax,katex}
rehype-mathjax rehype-katexEvery package.json would need to be updated with the new name (300+ packages in the collective alone)
Babel projects succeeded to do that. In my sense, we can keep old package with deprecated warning, and upload new packages. I attach the following link to babel release note.
https://babeljs.io/blog/2017/12/27/nearing-the-7.0-release.html#renames-scoped-packages-babel-x
Back then, not a lot of projects used scoped packages, so most people didn't even know they existed. You may also have had to pay for a npm org account back then, while now it's free (and supports non scoped packages, too). The issues with searching for scoped packages are solved and download counts work. The only thing left is that some 3rd party registries still don't support scoped packages, and I think we are at a point where it seems pretty unreasonable to wait on that.
If you want reasons why we prefer scoped packages:
- Naming is difficult: we won’t have to check if someone else decided to use our naming convention for their own plugin
- Similarly, package squatting
- Sometimes people create babel-preset-20xx or some other package because it's funny, and then we have to make an issue/email to ask for it back.
- People have a legit package, but it happens to be the same name as what we wanted to call it.
- People see that a new proposal is merging (like optional chaining, pipeline operator) and decide to fork and publish a version of it under the same name. Then, when we publish, it tell us the package was already published 🤔. Then, I have to find their email and email both them and npm support to get the package back and republish.
- What is an "official" package and what is a user/community package with the same name? We can get issue reports of people using misnamed or unofficial packages because they assumed it was part of Babel. One example of this was a report that babel-env was rewriting their .babelrc file, and it took them a while to realize it wasn't babel-preset-env.
So, it seems obvious we should use scoped packages, and, if anything, we should have done it much earlier 🙂!
they prevent name conflicts with other packages on the registry (this isn't a problem we've had without namespacing)
@wooorm had to negotiate to use package name sometimes, hadn't it?
My proposal reduces unneeded such task in the feature, but I agree that it makes a mount of tasks in a short while.
Babel projects succeeded to do that
Yes, they did, and it worked well for them.
Keep in mind, Babel is a different project, with a different community, and different goals.
Babel is very centralized, to the point that most of the babel plugins are in a couple monorepos.
Unified is much more decentralized, there are a lot of community plugins, and we have so far avoided scopes because we view "official" and "unofficial" plugins to be equally legitimate.
See #8 (comment)
My proposal reduces unneeded such task in the feature, but I agree that it makes a mount of tasks in a short while.
@wooorm may be able to speak to historical precedence, in terms of how often npm name clashes have been an issue.
Ir1d/rehype-mathjax#1 is the first time I've seen it come up.
Given that, it feels like it may be trading one small task (a name transfer) for hundreds of medium tasks (updating packages and imports).
Keep in mind, Babel is a different project, with a different community, and different goals.
I got it. Thank you for reminding me.
Unified is much more decentralized, there are a lot of community plugins, and we have so far avoided scopes because we view "official" and "unofficial" plugins to be equally legitimate.
See #8 (comment)
It's nice. As I'm new of this community (I did not know so much about that) and I respect the direction of your community.
@wooorm had to negotiate to use package name sometimes, hadn't it?
Yeah that sometimes happens! But I don’t think that’s a big problem. If that project was maintained, we could either collaborate with it, or use a different name. If it isn’t maintained, we can ask their owners to hand the name over, we typically have a good relationship with people, I never had any problems with that. Finally, if a package is truly unmaintained and the owner unreachable, then npm has a policy where they’ll hand packages over to new maintainers.
We also got the name remark and micromark on npm from other people, and some GH org names from GH. Yesterday I got iso-3166 (not part of unified) from npm. mdx on GH is used by someone else who is privately active on GH and we can’t reach out to, but then mdx-js is fine. All in all, not too worried about names clashing!
Alright, so to conclude, we do have the scopes, because we have the orgs. But we’re not using them: mainly as we’re decentralized and like that others can also publish “just as official” projects, and it’s a bit of a burden to update everything!
Thanks for proposing this, asking questions, I appreciate it!
Finally, if a package is truly unmaintained and the owner unreachable, then npm has a policy where they’ll hand packages over to new maintainers.
I've never read such cool policy. I have shame for my ignorance.
All in all, not too worried about names clashing!
Yeah, I appreciate to your kind explanations. Thank you!