-
Notifications
You must be signed in to change notification settings - Fork 12k
Inline inline.js #2307
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
Also, it's missing hash in the name. It might change in the future and break a hosted app. |
I've also encountered the issue with not having a hash on inline.js. Since it contains the lazy loaded chunks filenames, it also need to be updated along with them. This seems lika a major oversight, or am I missing something here? Now I manually add my version number to the inline.js filename, but that shouldn't be required. |
We had CommonsChunkPlugin misconfigured to remove the chunkhash in inline.js. Partially address angular#2307
Here is an ugly(?) workaround, a bit of bashackery:
It puts the contents of the inline JS output, in line in the index file where it appears to belong. The particular syntax bits above should work on both OSX and Linux, a common source of irritation with sed. In addition to working around the problem right here in this item (a lack of optimization), more importantly this works around the problem in several items that link to this one: as of early December 2016 the in-line file does not get a hash in its file name and therefore does not cooperate very well with permanently caching JavaScript assets. This fixes that. |
We had CommonsChunkPlugin misconfigured to remove the chunkhash in inline.js. Partially address angular#2307 Close angular#2899
Recent progress now emits the in-line file with a hash name. Here is an updated script to "in-line the inline".
This saves one request, for what is just a tiny bit of JavaScript anyway. |
This file no longer exists. Also with the advent of HTTP/2 there is little to no incentive to inlining in this scenario especially when coupled with the use of CSP. |
Are you sure? The way I see it it just got renamed into |
Long term caching. The file changes anytime another bundle changes. |
But don't we have the per-bundle hash for that? |
Long term caching was why the file was originally separate. Webpack would store the chunk names within the file. But it does not appear to do so anymore. So yes. We could consolidate the runtime file within main now. |
Even with HTTP/2 enaed, I think it would better to consolidate the runtime bundle with the main bundle. Just doesn't make sense to fetch a 8 KB file separately ... |
With HTTP/2 it would not actually be fetched separately but at the same time and in parallel with the other bundles. In real world scenarios, the difference would be incredibly minor as the 8kb would need to be downloaded either way. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This is a feature request as of beta.15, rest of the issue template elided.
Currently
ng build --prod
yields a set of files like so:Upon inspection of the the index.html and inline.js contents, it appears that the contents of inline.js were probably intended, at some point in the design or implementation process, to be inlined inside index.html, saving one HTTP round-trip in the results. Thus, a feature request to inline the inline.
Related to this, a question: it appears the styles could be included in the main bundle - is there a reason they need to be kept separate (costing another HTTP request) in a prod build? If not, please include in main bundle.
The text was updated successfully, but these errors were encountered: