Page MenuHomePhabricator

Should npm packages maintained by Wikimedia be scoped or unscoped?
Open, Needs TriagePublic

Description

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:

  • Helps prevent naming collisions
  • Helps establish provenance of the code

Cons:

  • Causes trouble for Windows users due to directory name length?

Event Timeline

Mholloway created this task.Dec 3 2019, 7:11 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2019, 7:11 PM

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

SBisson added a subscriber: SBisson.Dec 3 2019, 7:28 PM
MSantos added a subscriber: MSantos.Dec 4 2019, 4:36 PM
WDoranWMF moved this task from Inbox to Icebox on the Platform Engineering board.Dec 4 2019, 7:42 PM
daniel added a subscriber: daniel.

Pinging TechCom to have a look. Maybe an RFC is in order?

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.

Krinkle added a subscriber: Krinkle.EditedOct 21 2020, 8:06 PM

Example of a package we have on npm that's perhaps oddly not prefixed or namespaced: https://www.npmjs.com/package/api-testing

Mholloway updated the task description. (Show Details)Oct 21 2020, 8:09 PM
tstarling moved this task from Inbox to Watching on the TechCom board.Oct 21 2020, 8:09 PM

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.

Personally I quite strongly favor org-namespacing

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.

Joe added a subscriber: Joe.Oct 28 2020, 9:05 AM

I second @Mholloway as well. The reasons are both what @Demian said, and we're not going to risk naming collisions in the future.