Angular-cli: Inline inline.js

[kylecordes]

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:

$ ls -l dist
-rw-r--r-- 1 ubuntu ubuntu    523 Sep 23 11:57 index.html
-rw-r--r-- 1 ubuntu ubuntu   1388 Sep 23 11:57 inline.js
-rw-r--r-- 1 ubuntu ubuntu 833489 Sep 23 11:57 main.62117700d901524c314e.bundle.js
-rw-r--r-- 1 ubuntu ubuntu 188979 Sep 23 11:57 main.62117700d901524c314e.bundle.js.gz
-rw-r--r-- 1 ubuntu ubuntu   3970 Sep 23 11:57 styles.b52d2076048963e7cbfd.bundle.js

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.

[Igonato]

Also, it's missing hash in the name. It might change in the future and break a hosted app.

[bialad]

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.

[kylecordes]

Here is an ugly(?) workaround, a bit of bashackery:

# Remove the following when https://github.com/angular/angular-cli/issues/2307 ships.

echo '<script type="text/javascript">' >inline.tmp
cat dist/inline.js >> inline.tmp
echo >>inline.tmp
echo '</script>' >>inline.tmp

sed -i.bak 's/<script type="text\/javascript" src="inline\.js"><\/script>/MARKER\
/g' dist/index.html

sed -i.bak -e '/MARKER/ {' -e 'r inline.tmp' -e 'd' -e '}' dist/index.html

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.

[kylecordes]

Recent progress now emits the in-line file with a hash name. Here is an updated script to "in-line the inline".

#!/bin/bash
set -e

# Remove when https://github.com/angular/angular-cli/issues/2307 ships.

echo '<script type="text/javascript">' >inline.tmp
cat dist/inline.*.js >> inline.tmp
echo >>inline.tmp
echo '</script>' >>inline.tmp

sed -i.bak -E 's/<script type="text\/javascript" src="inline\.[0-9a-z]+\.bundle\.js"><\/script>/MARKER\
/g' dist/index.html

sed -i.bak -e '/MARKER/ {' -e 'r inline.tmp' -e 'd' -e '}' dist/index.html

rm inline.tmp

This saves one request, for what is just a tiny bit of JavaScript anyway.

[clydin]

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.

[dominique-mueller]

Are you sure? The way I see it it just got renamed into runtime.js, but still exists. Is there a reason this file exists separately and is not part of the main.js bundle?

[clydin]

Long term caching. The file changes anytime another bundle changes.

[dominique-mueller]

But don't we have the per-bundle hash for that?

[clydin]

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.

[dominique-mueller]

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 ...

[clydin]

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.
Either way this would be a breaking change; however, it is being actively considered.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}