Next.js: Shared dependencies between pages

[fhelwanger]

First of all, this project is amazing 👍

Right now, if I import the same dependency in different pages it's downloaded the first time I visit each page.

Let's say I have the following in both index.js and about.js

import moment from 'moment'

This way, if I visit index.js and then navigate to about.js moment will be downloaded twice.

Are there any plans about using something like CommonsChunkPlugin to prevent it?

[fhelwanger]

Also, let's say I have the following module:

let n = 1;
export default () => n++;

If different pages import this module, each one will have its own instance of it.

[dlindenkreuz]

Good point. This is basically a pessimistic (and realistic?) description of https://zeit.co/blog/next#automatic-server-rendering-and-code-splitting as long as common libraries aren't loaded from a central place.

[mihalik]

I've run into the same issue playing around with this and a large React component library. The component library has a lot of dependencies and is huge and it makes every page/json file huge. Something like CommonsChunkPlugin or a simple single shared chunk would help.

[fhelwanger]

I think this apply to redux too. This example uses a single page, but if I had multiple pages the store would be created for each one. If I don't have some kind of persistance, the app state would be lost in the navigation 😕

[impronunciable]

@fhelwanger. I put together a redux example on the wiki in case that helps with the discussion

[fhelwanger]

@impronunciable Yes, that was what I linked 😄

[impronunciable]

Oh haha didn't see it. Thanks!

[impronunciable]

@fhelwanger This was the example because is short but I was able to put together an exampke with multiple pages using the same technique

[fhelwanger]

@impronunciable I'll try to put together an example

[impronunciable]

Thank you!

[fhelwanger]

@impronunciable I'm very sorry, the example works with many pages 👍

These lines make it use the same store on the client

if (!window.store) {
  window.store = createStore(reducer, initialState, applyMiddleware(thunkMiddleware))
}

But anyway, it'll download any dependencies of my app like redux, react-redux, moment, etc... on each page right?

Depending on the app, this isn't ideal. Maybe using CommonsChunkPlugin from webpack to bundle together the dependencies would prevent it.

But the downside of bundling every dependency is that if dependency A is used only by one page, maybe it isn't worth loading it in every page.

It's a hard problem 😄

[dlindenkreuz]

@fhelwanger CommonsChunkPlugin only bundles dependencies into a CommonsChunk when they are actually commonly used by multiple modules.

Check out the minChunks property in CommonsChunkPlugin docs which lets you configure this behaviour. Of course, we would need an editable Webpack config #40 for that 😏

[fhelwanger]

@dlindenkreuz Nice! webpack is really smart 😄

[luisrudge]

any news on this one?

[caillou]

I am a bit late to the discussion. I have been working with the CommonsChunkPlugin on a client project recently, and I really like the idea of adding it to next.js.

@dlindenkreuz mentioned that an editable Webpack config #40 would be a requirement to add the CommonsChunkPlugin to next.js.

Alternatively we could start by not setting the minChunks property. This defaults to the number of chunks. Hence, a module that is required on every page would then be moved to the common chunk.

By doing so, we could also able to get rid of the externals configuration in server/build/webpack.js. My understanding is, that the externals are a hack to avoid bundling react, react-dom, next/* in every chunk.

The result would be a baseChunk.js. It would contain all the commonly used modules and the webpack code, which, as of now is shipped with every page.json as well.

[arunoda]

@caillou I think this is what you had in mind https://github.com/zeit/next.js/pull/286 :)
I also want this so badly.

[fhelwanger]

I think this issue can be closed now, it seems to be tracked in https://github.com/zeit/next.js/issues/253.

The use case I described in https://github.com/zeit/next.js/issues/118#issuecomment-256752393 is the same as there.