Page MenuHomePhabricator

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


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.


  • Helps prevent naming collisions


  • 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 Core Platform Team 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.