Ask questionsMaintenance of the bundled package manager

On two occasions I’ve dedicated my time to try to improve the package manager that ships with Node, and both experiences have been poor:


In the first case, due to a hot issue not being referenced/closed by a PR that addressed it, and me not knowing of that PR, the time I dedicated ended up being spent in vain. This was a little bit my fault for assuming that the problem still needed fixing, since the issue was still open and there was no announcement from the maintainers there that it’d been fixed. Still, better communication on the maintainers’ part would have helped avoid that scenario too.

In the second case, the community has been yearning for years for a change to a confusing logging behavior when installing fsevents on Linux. Four PRs in total have been submitted to address this issue:


8 months went by after I submitted my PR (the third one) before it was auto-closed, and another 9 months have gone by since another contributor has re-submitted my PR (the fourth one). In all that time and with much campaigning in the way of upvotes and comments (not to mention the hundreds from the addressed issue) we’ve been unable to attract sufficient attention from maintainers to get the patch reviewed and merged. This is a +42 −29 patch with tests.

NPM’s CLI, accepting pull requests, appeared as if it would welcome my generous contribution dedicated to Node users’ greater good. Instead, my contribution has been met with much indifference, which I believe to be unwarranted.

The pattern I’ve noticed in both of my experiences has been a lack of concern by npm Inc to communicate with its community in the pursuit of addressing issues together. It’s very discouraging that I have the will to improve this vital component of Node’s ecosystem, but that my labor goes largely unrecognized by the component’s maintainer.

Seeing as the Node.js TSC “is responsible for … a number of projects depended upon by Node.js Core,” I expect this will be a fitting forum to consider the efficacy of npm Inc’s stewardship of the package manager included in Node installations.

Are my observations of neglect isolated, or is there a greater set of cases broad enough to warrant some upheaval? If so, a serious discussion about the management of npm/cli with npm Inc would be warranted. (Can process improvements be implemented for triaging PRs? Can community members be recruited and granted privilege to help?) If management could not be improved, then perhaps stewardship of the CLI ought to pass to Node.js itself. Let this be the beginning of a discussion that may lead to solutions such as these.


Answer questions othiym23

Full disclosure: I was once employed by npm, Inc., and my duties included managing the CLI team, heading up community engagement with the CLI user base, and acting as a coordinator between npm and the Node.js Foundation. I am presently a member of the Node.js moderation team, although I don't believe it to be appropriate for me to participate in moderation of this discussion as I have an interest in it (and am now participating in it).

I am the furthest thing from a disinterested bystander, but it has been several years since I left npm, and I believe I have some distance and perspective now to match my previous level of investment. To be clear, there are points in the linked threads where you, @jacksonrayhamilton, mention me, but those points happened after I was no longer at npm, and the nature of my departure was such that it didn't make sense for me to continue to participate in the project in any form.

With that said, I don't believe this is a good forum for this discussion. While npm is bundled in official Node.js distributions, and while the Node.js project has a duty of care to its users that it be fit for purpose which extends to the things that it bundles, npm is in all other ways an independent project with its own governance, roadmap, priorities, and problems. I believe that the goal of the team working on the CLI is the same that it has always been, which is to make sure that the users of the npm CLI have as smooth and unsurprising experience when installing JavaScript packages as is practicable. I also believe that the size of the team (still very small) is vastly outstripped by the scale and level of expectation on the part of its user community (huge).

npm has always had unusually transparent governance. Even with all the tumult surrounding npm as a company over the last year or so, there have been several blog posts outlining the roadmap that the team is working from. npm has always had some kind of dedicated community site (whether that's Discourse or a GitHub issue tracker) for discussions, and its various maintainers have always been easily reachable on a wide variety of channels (occasionally too much so – I'm not the only npm maintainer to have been pushed deep into the red of burnout by trying to remain engaged and accessible to the broader JS community). It has a well-defined RFC process. It has a constellation of contributors who have given freely of their time and energy simply out of a desire to support the community of which they are a part.

However, as you have experienced, there are few guarantees for open source projects, even those backed by companies with a major stake in the outcome. As I mentioned above, the team is small, and time is short. Open source maintainers, particularly those of popular projects, never have enough time. Time to fix problems, but also time to share context and bring clarity to people as to why the project may or may not be adopting certain solutions or merging certain changes.

I think this is just reality, and not something that can be remediated by replacing one form of governance with another. Even if many more maintainers are added and more efficient processes are adopted to minimize overhead and ensure the timely consideration of proposed changes (or whatever weaknesses a given set of people feel should / must be addressed), somebody or some group of people still must exercise judgment and decide which changes are going in, and which aren't. And it is going to be difficult, if not impossible, for the maintainers to be able to explain their reasoning to everyone involved satisfactorily. Just keeping the team all facing the same direction is hard enough (management complexity grows combinatorily as the number of developers grows linearly), much less somehow finding the wherewithal to keep the thousands of external users aware of what the team's priorities are and why.

I'll put it plainly: there will always be situations in a project like npm where the users feel like the maintainers have dropped the ball. Sometimes that will be true, but more times there will be more going on than is immediately visible. As a potential contributor to a project with millions of other users invested in the tool meeting their own needs, you are not always going to get what you want, even if it seems like what you want is a small, self-evidently reasonable change. This is not something that can be fixed by changing who's responsible for making the decisions or reworking the process by which decisions get made; it's simply a consequence of popularity and living in a world of all-too-finite constraints. It sucks that you feel like your time and contribution weren't properly honored, but, even not being involved with npm in any capacity anymore, I feel absolutely confident in saying that there's no malice directed at you or any of the other participants in the threads to which you link by anyone on the project.


Related questions

Nominating @tniessen for the TSC hot 1
Meetings over the holiday Weeks hot 1
Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-12-04 hot 1
Early access to security releases hot 1
Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-07-31 hot 1
Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-03-13 hot 1
Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-11-27 hot 1
V8 - TSC meeting hot 1
Node.js Foundation Technical Steering Committee (TSC) Meeting 2019-08-07 hot 1
Nominating @tniessen for the TSC hot 1
Nominating @BethGriggs to the TSC hot 1
Next weeks meeting conflicts with Modules Team hot 1
Github User Rank List