2

Installing and managing packages using npm is great! What I don't find so great is the mess it can leave.

I've started using npm for both client and node dependency management and I've noticed lots of different arrangements for the various packages I rely on. Some have lib folders, some have src folders, some dist, some docs, some examples Etc. I understand that this is because generally these packages come directly from source.

My question is:

Is there a way of identifying or even automating the removal of any unneeded files, for deployment to production? I'm thinking: removal of any readme.md (easy enough I guess) or example files (probably easy enough).

Ideally I'd like to be able to calculate exactly what the dependency tree looks like from my entry point and delete unneeded / unused files ... This is obviously a lot harder for client packages that rely on images or fonts or HTML for example.

EDIT:

As pointed out by Alexander Mac (below) A good strategy for front-end dep's is to include client dependencies as dev-dependencies and build. So my question is only related to nodejs apps.

Lewis
  • 5,769
  • 6
  • 30
  • 40
  • 3
    You shouldn't deploy backend dependencies on production? You should install them with `npm i --production`. What about frontend dependencies, you can build them locally (with task runner such as gulp) and push only bundles to the server. – alexmac Apr 22 '16 at 18:55
  • - Alexander Mac fair point about the front end dependencies. Installing front end dependencies as dev dependencies and building makes sense. – Lewis Apr 22 '16 at 20:45

2 Answers2

1

I might suggest building your code (and deps) into one bundle with rollup.js or webpack2.

These module loaders leverage tree-shaking approach to include only the code that is actually used.

  • GREAT! I'm using Webpack on the client - I'll take a look and see if this explains what I need. Thanks. – Lewis Apr 24 '16 at 12:58
1

You can run: npm prune which will remove modules from ./node_modules not specified as dependencies in packages.json.

npm dedupe will remove duplicate dependencies by pulling equivalent modules up to the root ./node_modules/. I don't know how useful this is though. I did it and then realised there were a whole bunch of modules I was using indirectly which I could also use directly, so there's that.

A surefire way of doing this is also:

rm -rf ./node_modules ./bower_components npm install

It's good practice to do a clean build before release to production anyway.

Also, I use sinopia to cache modules locally, which relieves network traffic, so these re-installs are a bit less time intensive.