Webpack 4 followup

[gaearon]

Thanks to some titanic efforts from @andriijas, @bugzpodder and others we finally have Webpack 4 in master. Hopefully CI will pass.

Let's use this task to keep track of followup things to do? At the very least this looks suboptimal to me:

Why are we shipping a few hundred bytes of the runtime as a separate chunk instead of e.g. embedding it into the HTML? I suppose it would always be small so we could avoid the extra request.

I also think #4490 disabled scope hoisting (?) so we might want to keep track of what's necessary to get it enabled again.

Was there anything else?

---

• Can we stop bundling runtime as a separate file?
• When can we enable scope hoisting (and do we need to?)
• Reload times in DEV are still pretty slow

[marcofugaro]

Reload times in DEV are still pretty slow

Maybe we could try the autodll-webpack-plugin?

They're still working on supporting webpack 4

It will be deprecated when webpack5 comes out

[miraage]

Regarding Can we stop building runtime as a separate file?.

Docs:
https://webpack.js.org/configuration/optimization/#optimization-runtimechunk

Values of true and single are equal for projects with a single entry point.
I think it is still worth to keep it separated because this part of the code won't change unless webpack version is updated.

[andriijas]

I agree it looks verbose on newly created apps - we could document better the purpose of the runtime though. My understanding is that its better to have the runtime separated when you start to divide your app into multiple chunks (clients only need to download updated chunks when you deploy)

[gaearon]

I agree it’s good to separate it from the chunks but couldn’t it be always inlined in the HTML?

[miraage]

It could be. AFAIK https://github.com/numical/script-ext-html-webpack-plugin provides an option to inline a certain script into HTML.

[clearjs]

Since runtime changes rarely, serving it with HTML each time would be a waste. Currently we can enable caching and only download it once, and this happens while the other chunks are being downloaded. This also slightly reduces initial HTML download time, so requests for other bundles start earlier. It can also be pushed with HTTP/2 if needed.

[gaearon]

cc @sokra @TheLarkInn

[Graham42]

A heads up about inlining scripts. This would be a breaking change for people who are using a strong Content Security Policy (CSP) that blocks all inline scripts.

My preference would to be avoid inlining.