When NPM gets bumped, you start with an empty module cache.  To restore it with optimal dependencies:

cd baseapp && rm -rf node_modules && npm -g install
cd dependentapp && rm -rf node_modules && npm -g install
cd thirdlevelapp && rm -rf node_modules && npm -g install

 

My headaches described below were due to my npm module’s dependency clauses’ versioning stanzas. I had set dependencies to automatically update but clipped them to the current minor version. Eventually they got crusty, and npm actually stopped finding the versions I was demanding in a speedy fashion. Both edges of the upgrade knife can cut you, don’t let dependencies get too old. 🙂 Fuller explanation on SO.

Historical blathering follows… (continued…)

Five minutes into this javascript exploit video, you’ll understand why that massive stack of node modules in your app is BAD.  Nicely done.

And… 14 minutes in and he hits Moment.js… which is everywhere… with a straightforward tough-to-solve regex DDOS hack.

Then mongoose… then…

Diamond dependencies are everywhere, from dll dependency hell to running an upgradable linux distro to your node stack to figuring out your #include order.  Check out Titus’s perspective, it’s pretty tight.

I use my rad-scripts node module to quickly set up management and automation of my active projects.  I now have a couple private node modules:

  • mah-haus is my node module that mass-manages all my repos – it’s great; with one command I can completely sync my entire dev station when I start/finish a session
  • atci is for my AbetterTrader project and gives me all the dev tools I need to build, publish, and run continuous integration

Thanks node.js, I love my new automated life.  Should I publish these modules even though they have no real public use?  Nah, why pollute the npm-isphere?  But I will put this post here so I can use it for the module home pages.  😉  Carry on!