We currently have a mix of scoped and unscoped packages associated with the wikimedia org in npm. We should standardize on scoping or not scoping them to the wikimedia org, and make adjustments as needed. The trend is for packages to be scoped, but doing so has both pros and cons.
Pros:
Cons:
We haven't been using scoped packages in the past because Debian Jessie npm version was too old to support them, but nowadays that's not a problem anymore
I decided to scope @wikimedia/react.i18n because in my mind that makes more sense and is more like Composer which scopes everything, though there are some downsides to scoping pages for public consumption. npm makes an (initial) assumption that scoped packages are private. You have to declare them as public when you initially publish. Also, npm (not sure about yarn) will only allow a single registry per-scope. For instance, if we published packages to GitHub Packages, we'd have to select a different scope. However, using global scope doesn't fix this problem.
Example of a package we have on npm that's perhaps oddly not prefixed or namespaced: https://www.npmjs.com/package/api-testing
I don't think we need a strong policy on this per-se, a coding convention as we do with other naming would suffice. If I look at other orgs, there is quite often a mixture of some things being namespaced and some things not.
TechCom would, I think, we happy with FSG and others developing an informal convention around this unless there is something we need to converge on strongly.
Personally I quite strongly favor org-namespacing, but I was surprised to find that others disagreed, so opened this ticket for discussion. If FSG want to keep it open for discussion and eventual adoption of a convention, that's fine with me, otherwise we can just close it as declined and let the status quo be.
I concur. The simple information that a package is created by the WMF conveys a lot of helpful context: where to look for documentation, support, source code (without visiting npm.org), in what domain the package will be applicable, what problems it helps to solve etc. It makes managing packages easier (for ex. related packages are grouped together, this makes reading package.json easier, searching just wikimedia packages in node_modules easy, etc.) and generally it is a best practice.
I second @Mholloway as well. The reasons are both what @Demian said, and we're not going to risk naming collisions in the future.