Split vendor and app into separate files

[shrynx]

NOT AN ISSUE but a feature request.
imo, it would be beneficial for splitting the js bundle into app and vendor files.
My app code keeps changing but vendor dependencies rarely change. splitting into two files will be a lot beneficial for long term caching.

If this interests, i will be more than happy to make a pull request for this.

[gaearon]

Yeah I agree it’s a good idea.

@viankakrisna did some work in #1651 but it’s pretty complicated. Maybe we can start with something simpler. For now I would be open to taking the following implementation:

• src/index.js stays the main entry point
• If src/vendor.js exists, then anything imported there goes into a separate vendor bundle

[shrynx]

Okay i think my way of splitting vendor is quite different.
i just had a look to the fore mentioned pull request. it deals with dll (which i still not too familiar with)

webpack is super awesome
the commons chunk plugin takes can take a function, thus we can automatically determine all the vendors by checking if the import belongs to node_modules folder or not.

// this assumes your vendor imports exist in the node_modules directory
new webpack.optimize.CommonsChunkPlugin({
  name: 'vendor',
  minChunks: module => module.context && module.context.indexOf('node_modules') !== -1
}),

[gaearon]

I'm not sure this works well because some Node modules update much more often than others. I would like to keep user in control here.

[shrynx]

ahh i see the point. got it.

[shrynx]

@gaearon i'll try making a pull request by weekend for the way you mentioned src/index.js and src/vendor.js

[gaearon]

Sounds good!

[viankakrisna]

@gaearon actually i've moved the vendor entry point to ./src/vendor.js but no heuristics yet to enable the feature only if it exists (i could add another check in start.js and webpack config :p). I'll try to simplify it to a webpack plugin i guess.

@shrynx The common chunks plugin still runs on every build, so it does not solve the long build time for large project (can the build be cached? I actually haven't explore it ). I chose dll because then we can control when we want to build the vendor bundle.

As a side note, i haven't found a solution for this auto bundling the vendor yet. The closest one is this https://github.com/clinyong/dll-link-webpack-plugin but it requires user to use yarn.

My solution depends on the hash of vendor.js, yarn.lock (if exists), package.json, existence of the build in node_modules/.cache/vendor, and switches on prod / dev. I agree the ejected user will overwhelmed by the config right now, but i'll try to simplify it into a plugin (all help is welcome!).

[viankakrisna]

@shrynx for prior discussion of long term caching, see #210

[shrynx]

@viankakrisna i might be mistaken, but there are two separate issues.

• long term asset caching by browsers for vendor file.
• caching vendor libraries during compile time, so as to reduce build time.

of course they can be solved with a common approach (like your PR), but my feature request was of browser caching and not compile time caching (definitely a relevant issue !)

@gaearon just to make sure, should i be working on vendor splitting for browser cache or for both browser cache && build time ?

[viankakrisna]

Added a check for ./src/vendor.js existence here https://github.com/facebookincubator/create-react-app/pull/1651/files#diff-c0e4b3a84334c2e5d316b33e2b0d5c9bR7 It's now opt-in :).

[viankakrisna]

@shrynx yeah, but for a long term caching the bundle is still generated on compile time, is it not?

#1651 is solving those two issue that you have said, it's splitting the vendor and app code (solving long term caching) with it's own each build process (solving faster rebuilds). It's quite complex in the earlier iterations, because it's naively modifying webpack config without heuristics.

Right now that PR does not touch the webpack config if src/vendor.js not exists. so i think it's quite simple for ejected users (i hope).