4 ms·

Can you give me examples of this? Everything I've used regarding NPM has been awesome. Stupid easy to use and integrate.

Silhouette 11y ago
OK, here's an everyday example. Suppose you and I are working on a front-end project, all neatly set up with package.json and so on in place. We've been working on different new features, adding in a new package or two from NPM in the process. We both fetch each other's latest changes to in-house code from source control. What NPM command do we run to make sure we also have the same packages installed and are actually running the same code?
- overcast 11y ago
  package.json version control and npm update? npm install --save will install the package you want, and add it to package.json Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.
  - Silhouette 11y ago
    Unfortunately, the regular package.json and related npm commands are built around semver, and typically also only specify direct dependencies. Either of those alone is enough to violate the simple condition I gave many times over on a real project, because it means you can't in practice guarantee that two developers are even running the same code. It's actually worse with the latest NPM changes that flattened the tree in node_modules, because now there are order dependencies affecting which versions of things you get as well. The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well. In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.
    - Wintamute 11y ago
      Personally I don't find using npm shrinkwrap a chore at all. If npm 3+ notices a shrinkwrap file in the project it'll update it automatically, so most of the time you don't even have to think about it. We've been using npm 3 on multiple large projects spanning frontend and backend, being worked on by many developers, pushing code through CI into production many times a day and npm installing fresh in every environment. There are probably many thousands of nested dependencies in some projects. It works, nothing bad happens, it's fine. Npm comes with some trade offs, true, but also a long list of plus points as well. No system is perfect, but you're painting some calamitous disastrous picture here which simply isn't reflected in reality.
      - Silhouette 11y ago
        You've been using NPM3 on many large projects with many developers, many commits, thousands of nested dependencies, and not run into a single problem? If so, that is a remarkable achievement, and I hope you'll write up how you've done it somewhere. In particular, I envy whatever combination of dependencies and development platforms you get to work with, because I haven't seen a single project with no problems due to updates since NPM3 arrived, never mind all of them. (Edit: This is not intended to imply NPM3 is the only reason for the problems, only to define a comparable time frame.) Even if you're in an environment where shrinkwrap is working well, we seem to find transitive dependencies of installed packages that introduce bugs or break something without correctly updated semver with alarming frequency. As some of us were discussing here on HN the other day, this has happened so often with Gulp plugins over the past few months that one project I work on dumped the entire Gulp ecosystem (and instantly and dramatically improved developer productivity as a direct result).
        Wintamute 11y ago
        > and not run into a single problem? I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs, some of them due to dependencies breaking, but nothing calamitous or actually bad, and nothing out of the ordinary compared to other stacks and tools imo. Npm module churn can be annoying sure, but on the flip side its good to be getting incremental patch updates sometimes too. And with exact versions in package.json and shrinkwrap you can eliminate enough uncertainty that to all intents and purposes its really not a problem. > dumped the entire Gulp ecosystem Amen to that. Gulp plugin eco-system has been messed up for a year or more. We do all our frontend builds with npm scripts now, running the bare cli tools where possible, and reducing dependencies as much as possible (e.g. Gulp and all its plugins).

Silhouette 11y ago

OK, here's an everyday example. Suppose you and I are working on a front-end project, all neatly set up with package.json and so on in place. We've been working on different new features, adding in a new package or two from NPM in the process. We both fetch each other's latest changes to in-house code from source control. What NPM command do we run to make sure we also have the same packages installed and are actually running the same code?

overcast 11y ago
package.json version control and npm update? npm install --save will install the package you want, and add it to package.json Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.
- Silhouette 11y ago
  Unfortunately, the regular package.json and related npm commands are built around semver, and typically also only specify direct dependencies. Either of those alone is enough to violate the simple condition I gave many times over on a real project, because it means you can't in practice guarantee that two developers are even running the same code. It's actually worse with the latest NPM changes that flattened the tree in node_modules, because now there are order dependencies affecting which versions of things you get as well. The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well. In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.
  - Wintamute 11y ago
    Personally I don't find using npm shrinkwrap a chore at all. If npm 3+ notices a shrinkwrap file in the project it'll update it automatically, so most of the time you don't even have to think about it. We've been using npm 3 on multiple large projects spanning frontend and backend, being worked on by many developers, pushing code through CI into production many times a day and npm installing fresh in every environment. There are probably many thousands of nested dependencies in some projects. It works, nothing bad happens, it's fine. Npm comes with some trade offs, true, but also a long list of plus points as well. No system is perfect, but you're painting some calamitous disastrous picture here which simply isn't reflected in reality.
    - Silhouette 11y ago
      You've been using NPM3 on many large projects with many developers, many commits, thousands of nested dependencies, and not run into a single problem? If so, that is a remarkable achievement, and I hope you'll write up how you've done it somewhere. In particular, I envy whatever combination of dependencies and development platforms you get to work with, because I haven't seen a single project with no problems due to updates since NPM3 arrived, never mind all of them. (Edit: This is not intended to imply NPM3 is the only reason for the problems, only to define a comparable time frame.) Even if you're in an environment where shrinkwrap is working well, we seem to find transitive dependencies of installed packages that introduce bugs or break something without correctly updated semver with alarming frequency. As some of us were discussing here on HN the other day, this has happened so often with Gulp plugins over the past few months that one project I work on dumped the entire Gulp ecosystem (and instantly and dramatically improved developer productivity as a direct result).
      - Wintamute 11y ago
        > and not run into a single problem? I didn't say not a single problem: I said "its fine, nothing bad happens, it works". Of course there are issues, and bugs, some of them due to dependencies breaking, but nothing calamitous or actually bad, and nothing out of the ordinary compared to other stacks and tools imo. Npm module churn can be annoying sure, but on the flip side its good to be getting incremental patch updates sometimes too. And with exact versions in package.json and shrinkwrap you can eliminate enough uncertainty that to all intents and purposes its really not a problem. > dumped the entire Gulp ecosystem Amen to that. Gulp plugin eco-system has been messed up for a year or more. We do all our frontend builds with npm scripts now, running the bare cli tools where possible, and reducing dependencies as much as possible (e.g. Gulp and all its plugins).