Webpack workflow splitting vendor and app code efficiently

Question

I have had trouble finding sufficient Webpack documentation and examples to hash out an ideal dev workflow for my situation. Here are all the features that would make the workflow ideal:

1. Watching, ideally through Gulp, with efficient caching. (Don't think I need hot module replacement and suspect it might not fit into my dev environment well.)

2. Vendor modules (right now I have only npm packages, not all of them exposing UMD globals in their main file, if it came down to that) that are

   a. not parsed & re-compiled during watch (so recompilation is faster),

   b. do not receive a sourcemap (so browser devtools are faster to respond), and

   c. write to a distinct vendor.js bundle that browsers can cache separately from app bundles.

3. App modules that are

   a. explicit about all dependencies (i.e. import React from 'react'; even if React is actually globally exposed or something via #2),

   b. are re-compiled during watch, and

   c. do receive a sourcemap.

Most of what I have read in documentation or examples has not seemed to hit this workflow on the head.

While I do see in the docs how to create a vendor-specific bundle (reproduced here: Simple solution to share modules loaded via NPM across multiple Browserify or Webpack bundles), the simple example provided does not address 2a and 2b.

I don't see in the docs any ways to specify different compile-configurations (sourcemaps, etc.) for different chunks, or to create completely separate Webpack bundles with separate config files that can reference each other, unless by globalizing all vendor libraries and using them as externals (?), which isn't ideal ...

Also, I am curious whether Gulp users are using gulp-webpack or instead a setup like that provided in http://webpack.github.io/docs/usage-with-gulp.html. (I'm not sure how well the webpack-dev-server would fit into my dev environment so would like to stick to gulp-watch if possible.)

Am I missing something that other Webpack users know about? What's the best way to do this?

OR is it possible that Webpack is not the right tool for the job?

Answer 1

Watching, ideally through Gulp, with efficient caching. (Don't think I need hot module replacement and suspect it might not fit into my dev environment well.)

Use webpack-dev-server.

You don't really need Gulp for this but you can use its Node API with Gulp (I'm doing that).

Vendor modules (right now I have only npm packages, not all of them exposing UMD globals in their main file, if it came down to that) that are

a. not parsed & re-compiled during watch (so recompilation is faster),

I don't think unchanged files would be parsed or recompiled during watch.

b. do not receive a sourcemap (so browser devtools are faster to respond), and

Don't know how to do this one. I think source maps are either all in or all out. But you can use devtool: 'eval' which works much faster than source maps.

c. write to a distinct vendor.js bundle that browsers can cache separately from app bundles.

I think you're looking for split-by-name-webpack-plugin.

App modules that are

a. explicit about all dependencies (i.e. import React from 'react'; even if React is actually globally exposed or something via #2),

This will work. To require globally exposed libraries, use externals config option.

b. are re-compiled during watch, and

What has changed, will be recompiled (if you use webpack-dev-server).

This doesn't answer all your questions but I hope it's enough to figure out whether this works for you. I don't think “not watching libraries” is such a big issue as you say it is (there's very little perf penalty on rebuilding cached modules) and if you ditch sourcemaps and use devtool: 'eval', I'd say it's really fast. Finally, there's a new watching solution in the works for Webpack so you might want to give it a spin. It should have even better perf.