-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split vendor and app into separate files #2206
Comments
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:
|
Okay i think my way of splitting vendor is quite different. webpack is super awesome // 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
}), |
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. |
ahh i see the point. got it. |
@gaearon i'll try making a pull request by weekend for the way you mentioned |
Sounds good! |
@gaearon actually i've moved the vendor entry point to @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 i might be mistaken, but there are two separate issues.
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 ? |
Added a check for |
@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 |
Sorry for the silence. i had been little busy. i'll send up a pull request regarding this in a while (cleaning things up). i have one concern this process always generates |
That's very useful, but will old routes still keep same hashes when delete first route? |
Guys, how about making So
if This keeps control in user's hands and creates best practices pattern I used this pattern in times of webpack 1.x.x |
BTW I tried to use |
@JustFly1984 Nothing was merged, so there is no splitting. |
Can you update the status? Right now I feel like I getting need to use CRA for development and make production webpack config separate from CRA. I'm getting weird tensions in the team. One part against ejecting, another needs a build improvements. Please clarify your intentions about vendor splitting. |
Another project along the same lines as AutoDllPlugin: fliphub/d-l-l |
Why not this in webpack.config.prod.js: const vendors = require('../src/vendors');
...
entry: {
polyfills: require.resolve('./polyfills'),
app: paths.appIndexJs,
vendors,
},
...
plugins: [
new webpack.optimize.CommonsChunkPlugin(/* chunkName= */ 'vendors'),
...
], And in module.exports = ['react', 'react-dom', ...]; I kept every thing else (with |
Any news on this? |
I'm working on a PR |
Can't wait!
2017-09-18 22:59 GMT+08:00 Ayc0 <notifications@github.com>:
… I'm working on a PR
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2206 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACJseSE2bm9fDtEwI6botit633eDLdK0ks5sjoVhgaJpZM4Net1O>
.
|
I think it's done |
When and how to use it in CRA?
2017-09-19 12:21 GMT+08:00 Ayc0 <notifications@github.com>:
… I think it's done
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2206 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACJseXfvm-Tt7-CVFVrq7OyKVWayMkVUks5sj0FUgaJpZM4Net1O>
.
|
If the PR is merged, there will be a To add another vendors, you just have to fill the array with the npm module names, and if the file doesn't exist, there won't be any vendors |
but if you need this feature as soon as possible, you can eject the conf, add manually this MR (and others), and if a new version of CRA includes everything you need, you'll revert the eject (just revert the commit) |
They don't need to eject, they could use the release cut by @react-scripts-dangerous temporarily. |
@Timer how to use this feature right now? |
@ebhoren if you're willing to help test the feature, follow these instructions: #3145 (comment) |
This is superseded by #3878. |
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.
The text was updated successfully, but these errors were encountered: