Package-maintenance: Question on Publishing of Company Supported Modules

[lholmquist]

There is a publishing scenario that i was thinking about recently, that I wanted to bring up to this group to see what others thoughts were.

Lets say that a company has its own internal registry where they have node modules that they support for their customers. Those support node modules are scoped with the company name in their internal registry. This way, all the customer has to do is add a little something to a .npmrc file saying to install any @companyName modules from that registry. This isn't anything new, and i believe it is documented on npm's site.

The scenario I was thinking about, was what if the company also "owns" the @companyName scope on the upstream npm, and want to publish something there, either a "blank module" with just a readme, or maybe a mocked function that returns an error that maybe gives some information on how to get the supported version of the module. I can see this happening if the customer forgets to add the proper entry into an .npmrc file or if a user is searching.

Has anyone in this group run into this scenario, or have thoughts on it? I wasn't sure what npm's terms were related to this sort of thing. I know when the core-js module was outputting ads during npm installs many people were getting upset.

[vweevers]

I'd consider that squatting, because such a package doesn't serve the public, it only benefits (the customers of) the company.

[brodybits]

I think any company should have a right to use its own org name if it is available and publish whatever it needs into its own namespace, public if needed for any reason, just like an individual should have this kind of right.

[vweevers]

There are limits. See https://docs.npmjs.com/using-npm/disputes.html:

Some things are not allowed [..]:

1. “Squatting” on a package name that you plan to use, but aren’t actually using.
2. Putting empty packages in the registry. Packages must have SOME functionality. It can be silly, but it can’t be nothing. (See also: squatting.)

[lholmquist]

So i might have left out a bit of context. The company also publishes a "community" version of the module on npm, just not under the @companyName scope. So while i agree with the squatting argument, this might not be(?) . sort of a fine line there.

I don't think moving the module to the company scope is feasible since the module is already well established.

[ljharb]

It’s likely not squatting if you’re using your own company name as an org placeholder, for this very purpose - who else would have the right to use that org name?

[ljharb]

Separately, you can add an unscoped package to an org without renaming it.

[lholmquist]

Separately, you can add an unscoped package to an org without renaming it.

Right, i've done that with a few of my own personal modules when orgs first came out, but that was more for the easier administration of the modules for other team members.

[brodybits]

The company also publishes a "community" version of the module on npm, just not under the @companyname scope.

In a case like that, I would publish a company module that simply requires and exports from the "community" version. A possible advantage is that your company could decide to make custom enhancements in the "@companyname" scope at some point in the future.

[lholmquist]

Just wanted to circle back here to close this out. I had some offline discussions with @darcyclarke about this scenario and it was suggested that publishing a blank module in a company org is probably fine. And that possibly using a postinstall hook to error the install would be acceptable. This scenario is really only trying to solve the problem if a user who is using the supported module forgets to modify their config. So it is an edge case.