5 ms·

> Because all dependents are satisfied by 1.0.1, support agrees to grant Supreet’s request to delete 1.0.0. There are some good changes here, unfortunately thi

> Because all dependents are satisfied by 1.0.1, support agrees to grant Supreet’s request to delete 1.0.0. There are some good changes here, unfortunately this policy will still break projects that use "npm shrinkwrap" to lock down specific versions, which IMHO, anyone who wishes to retain their sanity will do. When this happens AFAIK there's no foolproof way to "patch" your npm-shrinkwrap.json with the new version without deleting it and re-running shrinkwrap, and thus possibly bumping versions of every other package as well. The usual recommendation seems to be "find and replace" the version in npm-shrinkwrap.json with a regex, which is fine if the package's dependencies didn't change but will break if a dependency is added. I'd love to know if there's a better way. FWIW, if you think this is a very rare occurrence, it's now happened to me 3 times in last few months, the latest being less than a week after the left-pad incident [1]. 1. https://github.com/chalk/ansi-styles/issues/15 https://github.com/chalk/ansi-styles/issues/15 2. GitHub issue with additional discussion here: https://github.com/npm/policies/issues/44 https://github.com/npm/policies/issues/44

xirdstl 11y ago
We also ran into this issue just last week and used the "find and replace" method. Here's one incredibly horrible solution (hack): publish your own "package" to NPM which depends on the shrinkwrapped versions of your dependencies. Per this policy, they won't delete your dependencies since your NPM package explicitly depends on them.
- kibwen 11y ago
  New startup idea: "Dependence As A Service". For a nominal fee we'll automatically upload a package that depends on any version of any other package that you desire, and we guarantee that we will never yield to any frantic, desperate pleas to excise these dependencies!
eblanshey 11y ago
Time to start committing dependencies to your VCS.
- tlrobinson 11y ago
  $ du -h -d0 node_modules 673M node_modules EDIT: Actually it looks like du is reporting double the size, it's really 337.2MB according to OS X Finder (apparently it's using 512 byte blocks on OS X https://stackoverflow.com/questions/23599131/why-is-du-command-showing-double-size-when-h-flag-is-sent https://stackoverflow.com/questions/23599131/why-is-du-comma...)
  - nostrademons 11y ago
    git annex? (I get your point, though. My node_modules is 490M, and that's from a package.json that fits in one screenful on a terminal window.)
  - jerf 11y ago
    So, fully serious and non-sarcastic question since I'm not a node developer, what is in that 673MB?
    - trump2016chalk 11y ago
      Awaiting a response to this as well
    - deleted 11y ago
      [deleted]
    - tlrobinson 11y ago
      It's mostly Babel and other build tools: https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32513c301 https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32... With npm every dependency gets it's own tree of dependencies, so there's tons of duplication. Also, this is using npm 2. With npm 3 that's approximately cut in half since it tries to flatten the hierarchy as much as possible, but I haven't switched to npm 3 yet (seems slower and still somewhat buggy)
      - jerf 11y ago
        "With npm every dependency gets it's own tree of dependencies, so there's tons of duplication." That sounds like the missing bit of info. If that is the primary problem, then the good news is that git actually ought to be able to re-de-dupe that stuff back down; checking it into git may not be as catastrophic as you'd initially think.
btilly 11y ago
There are some good changes here, unfortunately this policy will still break projects that use "npm shrinkwrap" to lock down specific versions, which IMHO, anyone who wishes to retain their sanity will do. I've been programming for closing in on 20 years, and have seen a wide variety of approaches to the dependency management problem over that time, under a number of names. My experience is that locking down the version of every single dependency causes you to push off the pain of changing dependencies for a long time, but the upgrade headache will be far nastier when it happens. There is less overall pain from constantly integrating new versions and fixing breakage as it happens. I doubt that the node.js community will realize this until they go through something like the series of remote code execution vulnerabilities that Ruby on Rails had a few years back. And then they find that all of their software is vulnerable and they can't get rid of the vulnerability until every library depends recursively on the latest version of everything so that you can get the security fix every place that you need it. That upgrade will be a series of insane nightmares.
- tlrobinson 11y ago
  Absolutely. Using shrinkwrap doesn't mean you should defer updating dependencies for weeks or months, but I've wasted enough time dealing with issues caused by minor differences in people's node_modules and things randomly breaking that I refuse to not use shrinkwrap. Advantages: 1. Ensures everyone is developing on the exact same versions of every package 2. We have a complete record of correctly working dependencies' versions in the source tree at all times 3. Some random package developer can't introduce a bug in my software by pushing a new buggy version of their package right before I cut a release Disadvantages: 1. You may not get bug fixes immediately. Solution: do a fresh `npm install` and `npm shrinkwrap` regularly (but not in the middle of testing a release branch, for example) 2. If someone unpublishes a version depend on you have to drop what you're doing and fix your npm-shrinkwrap.json Also, `npm deprecate` allows package maintainers to deprecate specific versions (e.x. if a vulnerability is found), and you'll get a warning when installing, even if you use shrinkwrap. I'm not sure how common it's usage is though.
cammsaul 11y ago
Switch to jQuery?

xirdstl 11y ago

We also ran into this issue just last week and used the "find and replace" method. Here's one incredibly horrible solution (hack): publish your own "package" to NPM which depends on the shrinkwrapped versions of your dependencies. Per this policy, they won't delete your dependencies since your NPM package explicitly depends on them.

kibwen 11y ago
New startup idea: "Dependence As A Service". For a nominal fee we'll automatically upload a package that depends on any version of any other package that you desire, and we guarantee that we will never yield to any frantic, desperate pleas to excise these dependencies!

eblanshey 11y ago

Time to start committing dependencies to your VCS.

tlrobinson 11y ago
$ du -h -d0 node_modules 673M node_modules EDIT: Actually it looks like du is reporting double the size, it's really 337.2MB according to OS X Finder (apparently it's using 512 byte blocks on OS X https://stackoverflow.com/questions/23599131/why-is-du-command-showing-double-size-when-h-flag-is-sent https://stackoverflow.com/questions/23599131/why-is-du-comma...)
- nostrademons 11y ago
  git annex? (I get your point, though. My node_modules is 490M, and that's from a package.json that fits in one screenful on a terminal window.)
- jerf 11y ago
  So, fully serious and non-sarcastic question since I'm not a node developer, what is in that 673MB?
  - trump2016chalk 11y ago
    Awaiting a response to this as well
  - deleted 11y ago
    [deleted]
  - tlrobinson 11y ago
    It's mostly Babel and other build tools: https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32513c301 https://gist.github.com/tlrobinson/1fba66be86f473ffe76312c32... With npm every dependency gets it's own tree of dependencies, so there's tons of duplication. Also, this is using npm 2. With npm 3 that's approximately cut in half since it tries to flatten the hierarchy as much as possible, but I haven't switched to npm 3 yet (seems slower and still somewhat buggy)
    - jerf 11y ago
      "With npm every dependency gets it's own tree of dependencies, so there's tons of duplication." That sounds like the missing bit of info. If that is the primary problem, then the good news is that git actually ought to be able to re-de-dupe that stuff back down; checking it into git may not be as catastrophic as you'd initially think.

btilly 11y ago

There are some good changes here, unfortunately this policy will still break projects that use "npm shrinkwrap" to lock down specific versions, which IMHO, anyone who wishes to retain their sanity will do. I've been programming for closing in on 20 years, and have seen a wide variety of approaches to the dependency management problem over that time, under a number of names. My experience is that locking down the version of every single dependency causes you to push off the pain of changing dependencies for a long time, but the upgrade headache will be far nastier when it happens. There is less overall pain from constantly integrating new versions and fixing breakage as it happens. I doubt that the node.js community will realize this until they go through something like the series of remote code execution vulnerabilities that Ruby on Rails had a few years back. And then they find that all of their software is vulnerable and they can't get rid of the vulnerability until every library depends recursively on the latest version of everything so that you can get the security fix every place that you need it. That upgrade will be a series of insane nightmares.

tlrobinson 11y ago
Absolutely. Using shrinkwrap doesn't mean you should defer updating dependencies for weeks or months, but I've wasted enough time dealing with issues caused by minor differences in people's node_modules and things randomly breaking that I refuse to not use shrinkwrap. Advantages: 1. Ensures everyone is developing on the exact same versions of every package 2. We have a complete record of correctly working dependencies' versions in the source tree at all times 3. Some random package developer can't introduce a bug in my software by pushing a new buggy version of their package right before I cut a release Disadvantages: 1. You may not get bug fixes immediately. Solution: do a fresh `npm install` and `npm shrinkwrap` regularly (but not in the middle of testing a release branch, for example) 2. If someone unpublishes a version depend on you have to drop what you're doing and fix your npm-shrinkwrap.json Also, `npm deprecate` allows package maintainers to deprecate specific versions (e.x. if a vulnerability is found), and you'll get a warning when installing, even if you use shrinkwrap. I'm not sure how common it's usage is though.

cammsaul 11y ago

Switch to jQuery?