npm Community Forum (Archive)

The npm community forum has been discontinued.

To discuss usage of npm, visit the GitHub Support Community.

Officially protected/locked scopes

Hey guys.

I’d like to make a suggestion, and since I’m not sure where to do that, I decided to drop this message via email. The friendly support replied and suggested I post it here instead, so here I go.
Apologies if it’s too much text.

NOTE: Apparently, as a new user I am only allowed to make mentions to two people in my post.
However, the system mistakes my scope name examples for user mentions (can’t really blame it…)
So, I’ve put a space after the @ in each example scope name…

Like many other people nowerdays, I use yarn workspaces and lerna to manage monorepo setups. Maybe - hopefully - npm itself will offer a feature similar to yarn’s workspaces in future.

My use-case is that I’m developing actual applications, not libraries, so the packages are mostly private and not published.
I use lerna to run certain commands across multiple packages in the workspace. For this, I use lerna’s --scope feature.
In several projects I “misused” the package scopes in order to have better control of my workflow: I’ve used scopes like “@ client” and “@ server”, I’ve used scopes like “@ electron” and “@ web”, so I could effectively have a number of packages with the same scope and the do something like “lerna run build --scope @ client/*”.
Basically, that’s a great workflow.

However, sometimes I worry what will happen if some user decides to publish packages under a scope like @ web. While I’m using “private”: true, I ensure that I won’t accidentally publish e.g. my “@ web/core” package, but I’m not sure what happens if another user publishes a package with the same name.
I guess there won’t be much trouble effectively, as the locally available package will be resolved before reaching out to the registry, but the situation simply becomes ambiguous.

What I’d like to suggest is… that you - npmjs - as a “governing power” introduce a couple of protected namespaces. This would of course need some time and consideration on your side or by the community, and some might complain that you are “overreaching your powers” by “blocking” certain scopes, but I personally think it would be a wise decision and beneficial for the ecosystem.

Here are a couple of examples that I think should be unavailable to userland when publishing to the registry:

@ local/*
@ client/*
@ server/*
@ core/*
@ common/*
@ native/*
@ shared/*
@ project/*
@ web/*
@ desktop/*

While this was just off the top of my head, my point is that scopes with such universal names should be unavailable for users to “block” them on the registry, on purpose or accidentally.

A great side-effect would be that the community could develop solid patterns for building large-scale modular applications in monorepos (using just lerna or lerna+workspaces).
There could be universally valid recommendations of how to scaffold larger projects without the complexity of git submodules and extensive scripting for workflow management: monorepos, lerna and ideally (yarn/npm) workspaces accomplish the same thing with much less complexity exposed to userland.

Having scopes similar to the ones I proposed blocked away from registry usage would allow the community - or npm itself - to make recommendations or establish conventions about large-scale apps built with the npm ecosystem.

So… Basically just another 2 cents on some topic…but I thought I’d give it a try :)