Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Update npm to v1.2.8000 #7797
I will review this PR, but based on the diff stat it appears that your solution is to only update the dependencies of npm as opposed to the top level npm module?
Is there no smaller more precise way to fix this issue?
To be clear, me rolling a new version of node 0.8 with this update does not fix people in production where their version of npm is broken, this is even true of the versions of npm in 0.10.X that were broken by this.
This only provides a bootstrap for people who can upgrade their version, but doesn't solve for those people who are broken in production today.
People using 0.8 in production are generally using 0.8.latest in development, and 0.8.latest in Travis-ci to test their modules.
This means that there is a year of bug fixes that they aren't getting. Their CI tests are failing, and they're unable to properly publish new versions of their modules, without going through an extra out-of-band process to update npm. This extra step is especially difficult on a CI system.
This change is a version of npm with all of the same improvements that are in 1.4, but with the spinner and loglevel set to the 1.2.x defaults, and sets the version number to 1.2.x. You had mentioned in #7789 that these were the blockers. If there are other reasons to object to this update, please list them so that they can be addressed.
People who is still using 0.8 value stability above all else (why use it otherwise?), so they probably won't be happy with newest npm (I see compatible settings, but an amount of changed lines looks the same in two PRs).
If it's about carets, maybe just update semver module leaving anything else as is?
@rlidwka I'd tend to agree with you, except in this case, there are some problems with that view of things.
It is actually not possible to "just make the registry work with old npm". We've increased in size by well over 20x since 1.2.30 was released. The assumptions that made sense a year ago no longer make sense today. Users are coming to me understandably confused and frustrated that the npm that a new release of Node ships with a year-old version of npm that no longer works reliably.
referenced this pull request
Jun 23, 2014
We want the module ecosystem and Node.js experience to continue to thrive -- it has been and will continue to be one of the crucial selling points of Node.
Clearly npm needs to move at its own pace, and a lot of things have been added that can improve the developer and publisher experience. Since npm is moving at a faster pace than Node, the community should know and understand how to upgrade their experience out of the normal release cycle of Node, similar to how people are used to doing so with say CPAN or gem.
The log level and spinner were just examples of changes that are hard to decipher in this 7.2MB patch, in which there are a lot of moving parts. What I'm trying to solve for is a mechanism that allows people to install a version of Node v0.8 and do
The Node installer therefore can be a bootstrap into a known good, working, and acceptable version of npm that we've decided to ship, with the added benefit if there's a feature that a user is looking for that is in a newer version of npm they are able to upgrade to that.
It is clear that the challenges for npm weren't sufficiently appreciated in the past and design decisions were made that make that compatibility especially difficult now, but solving constrained problems is the nature of engineering. We have together learned that lesson the hard way in Node. In the same way we've worked hard to solve compatibility issues in Node, let's work together to find a solution now.
"Should" is being asked to a lot of work here. I don't think this statement matches reality:
I still believe that it is insufficient merely to include a patch for
It is not realistic for us (by which I mean myself, as the chief maintainer of the CLI, and what time @isaacs can spend) to cherrypick those bugs onto a branch forked from 1.2.30, as there have been ~600 commits between then and the release of 1.4.16. This is very different from backporting targeted fixes from the
Here are my suggestions for getting us past this impasse, in order of my preference. None strike me as particularly pleasant, although I think Isaac's proposal is the least painful overall:
I don't consider it an effective use of the npm team's time to try to figure out how to backport all of the important fixes from 1.4.16 to a new 1.2.x release.
Can npm be reduced to a tiny script capable of only installing a package from npm registry without any (non-bundled) dependencies? I'm talking about something like
It can, but not easily. Even without the caching or
@isaacs and I have discussed the possibility of replacing the npm in the distribution with just
I don't think we need the npm team to backport many fixes into 1.2, we're only looking for help with the semver fix, as it's a blocker for people using the legacy distribution for installing.
If the concern is around old npm's publishing in a new world, then I think it's reasonable (albeit unfortunate) to message to the user that this version of npm can no longer safely publish and that they should upgrade, and here's a link on how to do that -- but you can start with "npm install -g npm".
Are you looking for me to do a PR with these changes?
It would be nice if npm bundled with core could be fixed such that Windows users could actually do that. Right now the first time you install a global module,
Basically on Windows, if you
If this is indeed "one of the crucial selling points of Node", then treat npm like it matters. We are here telling you that the arbitrary release scheme is making life harder for Node users, including people who are using Node and npm as part of grunt or yeoman, and don't even know what "npm" is.
You have an opportunity to improve their lives, and we are trying to help you do so. There is no one saying that they'd prefer to use npm 1.2.
I'm sorry to come across confrontational here, but frankly, when you say that you "value Node's module ecosystem", and don't follow that up with action, these words sound hollow to me.
Leading a project is more than just processing the rules arbitrarily. You are shipping broken software because the rules say so, yet you are the one in a position to change that rule. What is your priority?
There is no way to reasonably backport "just" support for
If you want to attempt this, go for it. The fork button is in the upper right.
That is indeed a problem. Node's pace has slowed, and npm's has increased. How can we address that? Can we make Node's pace increase?
Is this just a resource problem? How can we help? What do you need for this to be successful?
Even that doesn't have to be a blocker, though.
That's what #7789 did. npm 1.2 is ancient. It is not supported. It is broken in half a dozen ways.
I urge you to take a hard look at what's actually stopping you from shipping a Node v0.8 with a more modern npm version.
In the past, we always shipped new versions of npm with Node releases, and we have been running the npm tests regularly with each of the supported versions of Node. I see no reasonable argument for Node v0.8 sticking to npm 1.2.
What is the difference between taking the approach of "get to where a user can
What is the priority? Why does Node ship with npm in the first place?
It would be a lot easier to work together to engage in this discussion if you gave me something to work with, rather than platitudes about the nature of engineering. I can't help you reach your goal unless you tell me what it is.