Dan J Ford

Changing the NPM publishing process

March 23, 2016 by Dan J Ford

Now before the title angers you, I find NPM great and use it for most of my projects! The only thing I would change is how the publishing and un-publishing process works. This post is inspired by recent the recent event where a developer removed all of their modules from NPM after encountering issues with the kik legal team.

As such, this left loads of developers with broken builds and unsure what to do. This eventually resulting in the library, "left-pad", being un-unpublished.

This left me thinking, should a developer be able to un-publish their published packages? In my opinion there is only one use-case where a developer should be able to do this and this would be if they made a release they didn't mean to. I don't think that security problems with a package version justify un-publishing, this should be handled by the bumping up of the version number with deprecation / warning notices on the affected versions.

Disclaimer: Just a note, I have not fully studied the underlying mechanics of NPM, maybe what I will suggest has already been implemented.

TLDR: The publishing / un-publishing process needs more control and options added to it

Edit: One idea that I recently read that I quite like the look of is that NPM should introduce the feature that a package name is more tightly attached to a user, so that when you publish, you would do something like npm publish packageName@username. This would mean that multiple packages could exist in harmony e.g. npm install kik@azer or npm install kik@kik. Perhaps you wouldn't even need to use packageName as this could be taken from the package.json author field.

The Problem

The reason, apparently, that the packages such as left-pad were removed from NPM was that the developer, Azer Ko├žulu, had problems with the kik messenger legal team after they found that he had a module called Kik. And as such, NPM seemingly just removed his package from their systems. However, I think this could have been handled better.

As it is a legal issue, something most likely had to be done about it. But instead of just pulling the package from the system, perhaps it could have been handled such that a notification was added to the package saying "This package is being migrated to a new name due to encountering issues", offering the developer the chance to change their package's name to something else within a certain time period. After this would be done, then all future module installs (for a specified time) could be redirected to the new package name so that the developer doesn't lose all of their traffic and thousands of developers' builds will not break.

Edit: Turns out it might not be so much of a legal issue and perhaps the developer should have been able to keep the name.

Proposed NPM migration notice
Proposed NPM migration notice

With this redirect in place, every time an npm install is done, the developer could be reminded that this package has been renamed and they should change it in their package.json so that they won't encounter any problems.

Example

WARNING
The package, packageName, is being moved to the name: newName.
Make sure you update your dependencies to reflect the change.

Or perhaps NPM could even automatically update the dependency name in the package.json?

Example

WARNING
The package, packageName, is being moved to the name: newName.
We have automatically updated your package.json to reflect the change.

The Solution

Back to the initial problem, i.e. developers un-publishing their published packages.

In my opinion the solution to this problem would be to only allow a developer to remove their package if it has been under a certain time period i.e. if they haven't removed it within 2 days then it will forever remain Locked within the NPM ecosystem unable to change. Even then, perhaps we still shouldn't be given the power of completely un-publishing a module. Maybe, we should only be able to over-write previously published modules that do not have the aforementioned "Lock"?

Example Warning

npm unpublish randomPackage@0.0.1

Sorry, you can not unpublish "randomPackage" version 0.0.1.
It has been too long and / or too many developers depend on it.

However, this approach would cause problems for developers who make e.g. "Edge" builds which are forever changing. Maybe the solution is that we need a more controlled approach to publishing? For example, having options available such as maybe allowing a single "Edge flag" per project meaning that, this specific published version will not be given the aforementioned "Lock".

Example

npm publish --edge

or

npm publish --build edge

Final Note

This is only a short, brief write up of what I thought about this recent issue. If you have any thoughts about how you think the issue of un-publishing should be handled, let me know!

Another proposed solution I have found in another article is a proposal that all libraries should bundle their code before publishing.

This could be a good solution however, there might be issues with it if this method is not carried out with care. In my opinion it could become a problem that, if everybody starts bundling their dependencies in with their library, this could result in possible duplication of libraries and dependencies becoming very large.

Another problem with this approach is mentioned in the comments of the article, that there could be legal problems with the approach:

Article Comment
Article Comment
Like what I've written?