-
-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Webpack does'n lift common code up to ansector's level #7235
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
Comments
remove |
Why it doesn't make sense?? If pages have some common code with others in the same level of hierarchy - move code to one level upper than Page1 or is Code Splitting an end in itself at the expense of the flexibility of customization for developers ' needs? |
I would actually second this request—having a vendor file extracted from your code, for example, is nice, but if it's fetched dynamically via webpack, you have to wait for your javascript to download and execute before the vendor file request is made. On the other hand, if you extracted it into a top-level standalone file, you can add it as a Of course, I imagine you can take your extracted vendor file and place it into an html file (including the chunk hash) with This could also be solved for me if we could pass a function to the |
producing a lot of async common chunks may be usefull for novices, but we dont use webpack in a wild
|
by the way, the Parsel by default lift up common dependence. |
Lifting the common code would delay the loading of Page1 for no reason. If in a separate file it can be loaded in parallel to the loading of i. e. PageA. Lifting code to the parent will always cause unnecessary code to be loaded. You should try to avoid this and only load code when needed. You already told webpack to do this via the |
produsing a lot of bundles make harder work for adding scripts to a page on server side (discovering on relation to the page) |
@sokra I don't think this is a necessarily-true statement. If you have a dynamic import, that means that it's called from your application javascript code; but in order for that to happen, your application javascript code must have been downloaded and executed. This code is, for single-page apps, often blocking, because without it your page won't work at all. If you have several required such top-level scripts, then by making them blocking you can at least guarantee their order of execution. Additionally, by making them top-level, you benefit from the browser's look-ahead parser and get a head start on the request. if you have, say, a Anyways, it'd still be desirable for me to be have an option to pull out an app-wide vendor file as top-level, and I imagine it'd be beneficial for other SPA developers for the same reasons. like I mentioned above, though, I could also solve it by having a function for |
@sokra can we reopen this issue? I really think this is something that should be addressed. Thank you! |
ping @sokra. Should I just create a new issue? |
Bug report
What is the current behavior?
After compiling the project many bundles have common code
If the current behavior is a bug, please provide the steps to reproduce.
here is my config:
What is the expected behavior?
in case of switchin new behavior in wp4 off - webpack should lift all common code on to one level upper in whole bundles hierarchy:
for an example:
(all pages have their own bundles)
We have start page Page1 and 3 pages PageA, PageB & PageC to go from the Page1. If we have some common code in those pages (PageA, PageB & PageC) and default new behavior is switched off - we shode move common code into the Page1.
Other relevant information:
webpack version: 4.8.1
Node.js version: 10.0.0
Operating System: Windows Server 2008R2
Additional tools:
The text was updated successfully, but these errors were encountered: