Vendor/common-chunks configuration? about universal-redux

[bdefore]

@dts this has been newly added in 2.0. you can add the package names that you would like to pull into a vendor bundle inside the array in this setting of your project config: https://github.com/bdefore/universal-redux/blob/master/config/universal-redux.config.js#L163

[dts]

Ah! Good stuff, I'll start depending on the current revision. What are the default dependencies (in the name form that is expected in this list) that make up the default 4MB package? Is there a reasonable way to get that list?

[bdefore]

Here ya go: https://github.com/bdefore/universal-redux/blob/master/config/webpack.config.js#L17-L27

[bdefore]

Whatever you add to the vendorLibraries array will be concatenated to that list.

[dts]

Fantastic - what version/checkout should I stick to right now? I'm getting the following error when attaching to d1ff7c5:

Module not found: Error: Cannot resolve 'file' or 'directory' <app>/node_modules/universal-redux/lib/client.js in <app>
[0] resolve file
[0]  <app>node_modules/universal-redux/lib/client.js doesn't exist
[0]  <app>/node_modules/universal-redux/lib/client.js.json doesn't exist
[0]  <app>/node_modules/universal-redux/lib/client.js.js doesn't exist
[0]  <app>/node_modules/universal-redux/lib/client.js.jsx doesn't exist
[0] resolve directory
[0]  <app>/node_modules/universal-redux/lib/client.js doesn't exist (directory default file)
[0]  <app>/node_modules/universal-redux/lib/client.js/package.json doesn't exist (directory description file)
[0] [<app>/node_modules/universal-redux/lib/client.js]
[0] [<app>/node_modules/universal-redux/lib/client.js.json]
[0] [<app>/node_modules/universal-redux/lib/client.js.js]
[0] [<app>/node_modules/universal-redux/lib/client.js.jsx]

[bdefore]

@dts i wouldn't advise checking out universal-redux directly, but making a project separately that includes universal-redux as a dependency in its package.json (the latest, 2.0.0-beta11 is what you should work from for now in order to have access to the vendorLibraries option).

[dts]

@bdefore: I'm getting the same error when I depend on universal-redux 2.0.0-beta11, beta4 works fine - the hiccup is that it is trying to find lib/client.js, when it looks like it should be src/client.js. Though, if I change it to 'src/client.js', it complains of other errors that indicate that it's not properly babelizing the src/client.js and I may be not totally understanding what's going on.

[bdefore]

lib/client.js is the babel compiled version, and that is the correct path. do you not have a lib directory in node_modules/universal-redux?

can you put your universal-redux.config.js into a gist for me? also your webpack configuration output from npm run dev with verbose set to true in the config.

[dts]

It sounds like npm doesn't install correctly when you change the version number in the package.json and then reinstall - when I rm -rf'd away node_modules and re-installed everything is peachy. Now, however, I realize that the vendor libraries functionality is limited to the production mode, not the development mode. Am I reading that correctly? It produces two files in prod, but only one in dev.

[bdefore]

That's mostly correct, but in fact, no bundle files are created locally in dev, since it's the Webpack HMR dev server offering up all of the JavaScript. But if you run npm run build, you'll see the main and vendor JS files show up in your /static/dist directory.

[dts]

That makes absolute sense - is there a way to split things up in Dev? So that HMR dev server serves up an infrequently-changed vendor file as well as an always-changing app file?

[bdefore]

I suspect that it is possible, but I'm not sure I know what benefit would come from an app/vendor split in that case.

[dts]

I think one bottleneck for speed in hot-loading is that it's busy writing giant libraries over and over into a 4MB file. If we only make webpack write the smaller app-specific file every time a change is made there is less stuff to write.

[bdefore]

Webpack is already pretty savvy during rebuilds to only recompile the parts that have changed. That's why the first build takes considerably longer than subsequent ones.

[dts]

Oh, I'm sure it's not recompiling everything - but just writing a big file is slower than writing a small file. I'm not convinced it'll be a ton faster, but every 100ms counts in my dev cycle. I was wondering if I could tell the difference in speed.

[bdefore]

I think we're ok to close this one, but feel free to open another if you'd like to request enhancement for code splitting in dev.