{"action":"created","issue":{"url":"https://api.github.com/repos/nodejs/LTS/issues/37","labels_url":"https://api.github.com/repos/nodejs/LTS/issues/37/labels{/name}","comments_url":"https://api.github.com/repos/nodejs/LTS/issues/37/comments","events_url":"https://api.github.com/repos/nodejs/LTS/issues/37/events","html_url":"https://github.com/nodejs/LTS/issues/37","id":103650978,"number":37,"title":"npm in 0.10 LTS","user":{"login":"othiym23","id":418097,"avatar_url":"https://avatars.githubusercontent.com/u/418097?v=3","gravatar_id":"","url":"https://api.github.com/users/othiym23","html_url":"https://github.com/othiym23","followers_url":"https://api.github.com/users/othiym23/followers","following_url":"https://api.github.com/users/othiym23/following{/other_user}","gists_url":"https://api.github.com/users/othiym23/gists{/gist_id}","starred_url":"https://api.github.com/users/othiym23/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/othiym23/subscriptions","organizations_url":"https://api.github.com/users/othiym23/orgs","repos_url":"https://api.github.com/users/othiym23/repos","events_url":"https://api.github.com/users/othiym23/events{/privacy}","received_events_url":"https://api.github.com/users/othiym23/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/nodejs/LTS/labels/lts-agenda","name":"lts-agenda","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-08-28T05:32:22Z","updated_at":"2015-08-31T20:16:26Z","closed_at":null,"body":"As a followup to [a discussion I had with @jasnell and @Fishrock123 on Twitter](https://twitter.com/jasnell/status/637082638642081792), I'd like to help this WG and the TSC figure out how the 0.10 release series deals with npm. For the most part, @zkat is the npm CLI team member responsible for our LTS strategy, so this is mostly just to capture the discussion I was having with James and Jeremiah on Twitter, and maybe give Kat some additional context.\r\n\r\nThe npm CLI team would like to officially discontinue support for `npm@1`. There hasn't been a new release of `npm@1.4` since [September 13th, 2014](https://github.com/npm/npm/releases/tag/v1.4.28), and at the time that `npm@1.4.28` was released, the npm team didn't plan on continuing to support `npm@1` development beyond the release of `npm@2.0.0` [on that same day](https://github.com/npm/npm/releases/tag/v2.0.0). Our policy as a support organization has just been to ask people who encounter one of the many issues with `npm@1.4.28` to upgrade to `npm@latest` as a first step, so npm actually stopped supporting `npm@1` a long time ago.\r\n\r\n`npm@1.4.28` is very familiar to many, if not most, Node users, because it's been bundled with Node.js 0.10 since 0.10.32 was released on September 16th, 2014. At the time `npm@2.0.0` was released, there were concerns expressed about including an npm including breaking changes in npm in the middle of a stable Node release series. This frustrated me at the time, but in retrospect it looks pretty reasonable.\r\n\r\nA _lot_ of changes have been made to npm since then (including several security fixes that affect users of `npm@1.4.28`), so as we think about moving Node 0.10 into LTS, it's worth taking another look at this and figuring out how to handle npm LTS in a way that works well for the LTS WG and for users depending on stability in 0.10 LTS.\r\n\r\n## Concerns\r\nThe main areas of concern are `npm@1`'s lack of forward compatibility with `npm@>=2` features and the primary npm registry, fixes to security flaws in `npm@2` that also affect `npm@1`, and changes included in `npm@2` that might have an adverse impact on LTS users of the version of npm bundled with Node 0.10.\r\n\r\n### Forwards incompatibility of `npm@1` with scoped packages\r\nOne of the most significant changes in `npm@2` is its support for scoped packages. There was a [lot of deliberation](https://github.com/npm/npm/issues/5239) around the design of scoped packages, and the choice of the format `@scope/name` for scoped package names was designed to cause as little hassle for users as it possibly could.\r\n\r\nUnfortunately, since we didn't plan for `npm@1` lasting beyond the rollout of scoped packages, we didn't do much testing of what happened when users tried to install scoped packages with `npm@1.4.28`. It turns out that `npm@1` ignores the leading `@` in scoped package names and treats the rest as a GitHub shortcut, which can result in the very confusing situation of a user thinking they've installed an npm private package they shouldn't have access to, when in fact they've installed a package from GitHub (which might not be the package they were expecting).\r\n\r\nIn addition, the registry changes to support private packages include a switch from using HTTP Basic authentication to bearer tokens (and also changes when authentication information is sent with npm requests – the registry needs to know who's making a request to decide if they're entitled to view any information on private packages). `npm@1` is increasingly ill-equipped to deal with current registry architectures, which includes not just npm, Inc's registry (and its npmE on-premise registry product), but also third-party registry projects that have added their own support for scoped and private packages, like sinopia, cnpmjs, and (I believe?) Artifactory.\r\n\r\nThe support for scoped packages is itself not a breaking change, but backporting all of the necessary code from `npm@2` to `npm@1` (including all the fixes made related to scopes since `npm@2.0.0` went out) is enough work to render supporting scopes in `npm@1` practically infeasible.\r\n\r\n### Security fixes in `npm@2` affecting `npm@1` users\r\nAs I mentioned above, there are a few security fixes in `npm@2` that affect `npm@1` users. I think / hope this is everything, but it's possible I overlooked something:\r\n- [`b9474a8`](https://github.com/npm/npm/commit/b9474a843ca55b7c5fac6da33989e8eb39aff8b1) `fstream-npm@1.0.5`: Stop publishing build cruft (`config.gypi`) and per-project `.npmrc` files to keep local configuration out of published packages.\r\n- [`300834e`](https://github.com/npm/npm/commit/300834e91a4e2a95fb7fb59c309e7c3fc91d2312) `tar@2.0.0`: Normalize symbolic links that point to targets outside the extraction root. This prevents packages containing symbolic links from overwriting targets outside the expected paths for a package.\r\n- [`0dc6875`](https://github.com/npm/npm/commit/0dc68757cffd5397c280bc71365d106523a5a052) `semver@4.3.2`: Package versions can be no more than 256 characters long. This prevents a situation in which parsing the version number can use exponentially more time and memory to parse, leading to a potential denial of service.\r\n\r\nSince the fix to semver was made to a version of semver that includes one of the breaking changes included in `npm@2`, addressing it in `npm@1` wouldn't be as simple as updating npm to use a newer version of `semver` – it would be necessary to fork `semver@2` and backport the fix to it.\r\n\r\n### Breaking changes in `npm@2`\r\nThe changes most pertinent to LTS discussions are in bold.\r\n- [`df4b0e7`](https://github.com/npm/npm/commit/df4b0e7fc1abd9a54f98db75ec9e4d03d37d125b) [#5518](https://github.com/npm/npm/issues/5518): **support passing arguments to `run` scripts**.\r\n- [`4378a17`](https://github.com/npm/npm/commit/4378a17db340404a725ffe2eb75c9936f1612670) `semver@4.0.0`: **prerelease versions no longer show up in ranges**; `^0.x.y` behaves the way it did in `semver@2` rather than `semver@3` ([`ea547e2`](https://github.com/npm/npm/commit/ea547e2) in `semver@3`: `^0.x.y` was functionally the same as `=0.x.y`).\r\n- [`c2cccd4`](https://github.com/npm/npm/commit/c2cccd4bbc65885239ed646eb510155f7b8af13d) / [`npm/npm-registry-client@ba6b73e`](https://github.com/npm/npm-registry-client/commit/ba6b73e351027246c228622014e4441412409bad) `npm-registry-client@5.0.0`: [npm/npm-registry-client#92](https://github.com/npm/npm-registry-client/issues/92): Move `/whoami` endpoint out of the package namespace (to `/-/whoami`).\r\n- [`c6ddb64`](https://github.com/npm/npm/commit/c6ddb6462fe32bf3a27b2c4a62a032a92e982429) npm requires Node >= 0.8.\r\n- [`021770b`](https://github.com/npm/npm/commit/021770b9cb07451509f0a44afff6c106311d8cf6) lifecycle: do not add the directory containing node executable.\r\n\r\n## Possible solutions\r\nHere are two ways we could fix this problem for 0.10 LTS:\r\n\r\n### Include `npm@2` in 0.10 LTS\r\nThe npm CLI team is getting close to making `npm@3` the version of npm intended for general use. It's had a lengthy development cycle and a pretty extensive beta, but since it includes a nearly complete rewrite of the installer, we've planned from the beginning of the `npm@3` beta to support `npm@2` and `npm@3` in parallel, probably for at least six months. This makes it a much easier thing for us to support going forward (in fact, right now I'm planning on `npm@2` being the npm major version included in Node 0.12 and 4.0 LTS, assuming both of those have LTS support). In addition, it includes all the security fixes and also works _much_ better with current npm registry architectures.\r\n\r\nThat said, it's up to the LTS WG and the TSC to decide if the breaking changes enumerated above are low-risk enough to justify inclusion in LTS. I like this solution because it requires much less work from the CLI team, and we've actually planned to support `npm@2` for a while anyway.\r\n\r\n### Release an `npm@1.4.29` that encourages users to upgrade to `npm@2`\r\nAs I hope I've made clear, backporting the security fixes and forward compatibility changes necessary to make `npm@1` usable _without_ including any breaking changes is more than the CLI team is able to take on. However, it would not be very difficult to put together a new version of `npm@1.4` that includes two changes:\r\n\r\n1. Exit with an early error and a helpful message if users attempt to install scoped packages.\r\n2. _Every_ time the CLI is run, print out a deprecation warning _strongly encouraging_ users to upgrade to at least `npm@2`.\r\n\r\nThat would address the most significant forwards compatibility issue, along with making it fairly easy for users to figure out what they need to do in circumstances where they're blocked.\r\n\r\nThese are just ideas I've come up with, and the team is open to other suggestions.\r\n\r\nSo that's the story with 0.10. If the WG decides that some form of including `npm@2` is the way to go, @zkat, as `npm@2` maintainer, will be the npm point of contact. If the WG decides to stick with `npm@1.4`, I'm probably the best person on the CLI team to handle things, as I'm the member of the team who's got the most familiarity with its code. Kat and I are both happy to participate in discussions related to this and show up for LTS WG and TSC meetings discussing them. Just let us know where we're expected and when and we'll be there."},"comment":{"url":"https://api.github.com/repos/nodejs/LTS/issues/comments/136487033","html_url":"https://github.com/nodejs/LTS/issues/37#issuecomment-136487033","issue_url":"https://api.github.com/repos/nodejs/LTS/issues/37","id":136487033,"user":{"login":"jasnell","id":439929,"avatar_url":"https://avatars.githubusercontent.com/u/439929?v=3","gravatar_id":"","url":"https://api.github.com/users/jasnell","html_url":"https://github.com/jasnell","followers_url":"https://api.github.com/users/jasnell/followers","following_url":"https://api.github.com/users/jasnell/following{/other_user}","gists_url":"https://api.github.com/users/jasnell/gists{/gist_id}","starred_url":"https://api.github.com/users/jasnell/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jasnell/subscriptions","organizations_url":"https://api.github.com/users/jasnell/orgs","repos_url":"https://api.github.com/users/jasnell/repos","events_url":"https://api.github.com/users/jasnell/events{/privacy}","received_events_url":"https://api.github.com/users/jasnell/received_events","type":"User","site_admin":false},"created_at":"2015-08-31T20:16:25Z","updated_at":"2015-08-31T20:16:25Z","body":"We only had three on the call today so we're going to defer this discussion to the next LTS call."}}