Sweetalert2: Rename package to @sweetalert2/sweetalert2

Created on 24 Sep 2019  路  3Comments  路  Source: sweetalert2/sweetalert2

GitHub Package Registry is in public beta stage now :tada: :tada: :tada:

What does that mean for us? Well, there's a small note in their docs:

Note: GitHub Package Registry only supports scoped NPM packages. Scoped packages have names with the format of @owner/name.

So I published the package with the scope: https://github.com/sweetalert2/sweetalert2/packages/26122


The sweetalert2 package was published 3.5 years ago in https://github.com/sweetalert2/sweetalert2/issues/69 and at that time I didn't put much thinking into naming. If I would name this package today, I'll go with @sweetalert2/sweetalert2 because that's IMO logical and aligned with GitHub repo, no repo can be without an author/organisation, or in other words a scope.

As we're getting close to the next major release, I propose the change in the package name:

- "name": "sweetalert2",
+ "name": "@sweetalert2/sweetalert2",

Would like to hear your thought and objections @gverni @zenflow @toverux, other opinions are of course welcome as well. Thanks!

Most helpful comment

Yup, a strong reason to use a package name scoped to the organization is to align with Github Package Registry's requirement for it.

Instead of deprecating the existing npm package and making people update the package name to get new releases, maybe we can continue to update sweetalert2 as a mirror of @sweetalert2/sweetalert2. It shouldn't be any burden, thanks to our CI/CD infrastructure.

All 3 comments

Ha! I gave my opinion about SweetAlert2 packages names a few times in the past, always in favor of a @sweetalert2 scope for _all_ of our packages. No matter the use case, I think scopes are good and that npm should never have allowed non-scoped package names. This created so much problems, conflicts and global scope pollution.

Yup, a strong reason to use a package name scoped to the organization is to align with Github Package Registry's requirement for it.

Instead of deprecating the existing npm package and making people update the package name to get new releases, maybe we can continue to update sweetalert2 as a mirror of @sweetalert2/sweetalert2. It shouldn't be any burden, thanks to our CI/CD infrastructure.

I would say keeping a mirror is a nice bow, but also a notice would be nice, to let people know the recommended way of doing things :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Spidersouris picture Spidersouris  路  3Comments

SasSam picture SasSam  路  3Comments

eestein picture eestein  路  4Comments

mayvn10 picture mayvn10  路  4Comments

WillGoldstein picture WillGoldstein  路  3Comments