-
-
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
Webpack: Set an alias to vendor dependencies and add vendor chunk #164
Comments
How does this play with npm addons? Like Generally I'm very much pro this idea, on both counts. We should use flat bundles if possible, and we should split React code into a separate chunk. |
@gaearon I was able to make it work for my repo and ditched it back while ago, so need some refresh. It's not straightforward, but definitely possible. |
I use this in prod and there is little caveat. Just setting alias won't improve performance, it also should be added to 'noParse' and to make it work with reactDom or Router
So I assume same approach is good for addons. |
The problem is that modules like |
@gaearon I will take a look and do it as part of the upcoming PR. |
We will likely do this as part of #210 whenever that effort is revived. |
Want to discuss this before opening a PR, since I am not sure my vision is aligned with the philosophy of the project.
In short, setting 'react' and 'react-dom' as webpack's
resolve:alias
can visibly improve dev-rebuild time since it will be using pre-built dependencies.This can de done by setting an alias to pre-built
react
andreact-dom
in dev config + alias to.min
version in prod.(optional) Define a
vendor
chunk and specifyreact
andreact-dom
there also.I guess, only first option improves build times, not sure of the built impact of the other one, but having two default chunks may teach beginners one of the common approaches, since I assume that a lot of learning will be done by reverse engineering webpack's config after
eject
. And by setting a standard for managing pre-compiled dependencies, beginners may be able to avoid long-term frustration with slow rebuilds that, subjectively, tend to add up really fast. (it seemsember-cli
is taking this approach by default, but their philosophy is different)Also am aware that there is DllPlugin approach, but not sure if there are any drawbacks for maintainers long-term and it may not be as easy to gasp by beginners as in mentioned above scenario.
The text was updated successfully, but these errors were encountered: