On Wednesday, November 30, 2016 at 6:46:33 PM UTC+1, Tom Fennelly wrote: > > Hi. > > I'm just wondering what might be the risks associated with manipulating > the contents of the node_modules folder outside the normal "npm install" > etc commands. IOW ... are there reasons why the a raw "drop in" of packages > into the node_modules is a bad idea Vs doing it through the normal "npm > install" mechanisms? >
TL;DR: it's not a problem if you replace *npm-cli* tool with another capable tool. It's basically about convenience. For example, if you've tried yarn (the Facebook's new thingy and npm-cli replacement), it messes up with your node_modules. If you try some npm modules themselves, they can do it too (for example: fix-dropbox-node_modules-symlinks). Having your module version numbers in package.json, now that's the real deal. What does npm-cli offer: - keeps track of versions and updates stuff for you, - takes note of what's a prod dependency, what's a dev dependency, peer dep etc, - allows for cross-platform stuff. There's more stuff, but these are, I think, the most important points. The way I see it, only the last thing might bite you hard, but let's go over those points. 1. Versions and updates Like I've said, yarn does package version management. Bower does it too. Many tools do, even Sublime or WebStorm can do it for you. The thing is, pick a good thing that you can repeat in production environment and on every dev's workstation, and you're probably ok. If your tool can *also* update package.json, you're golden - even people who don't use your tooling can probably repeat your steps (or run your one-liner install/setup/config script). As for updates - if you're "manually" (or by other tool than npm-cli) updating a package version, but still plan to ship without node_modules, you might lose the correct package version. If your other tool is automated, you can simply reuse package.json or something like that, but if you're getting a new module by actually downloading it and saving into node_modules/, you might forget to update your package management. So, unless you ship node_modules/ directory with all your code, this might be a problem. Again, tools like yarn can update on their own, so no issue. 2. Dev, prod, test, peer etc dependencies Ah, basically the same. If your replacement tool supports this, no risks. If it doesn't, the risk is again that prod doesn't get a critical module or that devs work with different versions of modules or simply that your git repository is huge and checkout and deployment takes forever. 3. Binary modules Say you're installing redis and hiredis. hiredis is a binary package. If you drop in your own version manually, and you're actually shipping the node_modules/ folder, your colleague might be using a mac or windows (guess what I'm using :P), so it won't work for them. But again, tool that takes care of it, takes the pain away. -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/07e0757b-d736-4ecf-83d6-5a00caa6519c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
