feat(target): support electron preload async chunk loading

[kwonoj]

What kind of change does this PR introduce?

This is proposal feature PR to extend current webpack's target support for Electron (http://electron.atom.io/), named electron-preload. Please find below the description for what it's for with latest Electron changes.

What is preload script?

As name stands for, it is a script that will be loaded before other scripts run in the page. This script will always have access to node APIs no matter whether node integration is turned on or off (https://electronjs.org/docs/api/browser-window).

This script will be evaluated & executed before any web page load occurs when it's specified in option.

What changes in this PR?

Technically preload script shares majority in common with electron-renderer target. Only notable difference is it is not available to use JSONPTemplate to load async chunks: preload script doesn't have entry HTML, neither have known-lifetime document existence to attach jsonp functions into. In result, using await import() in preload script with electron-renderer won't work.

In contrast, preload script must have node.js api access all time, which means it can use NodeTemplate instead for async chunk loading. This PR makes new target inherits electron-renderer, swaps out JSONP to NodeTemplate.

Other targets like async-node or electron-main can't be used then?

Both target allows NodeTemplate but effectively defeats all specific configuration required for electron's renderer processes like Electron renderer external config and vice versa.

Why do you think this is important to be included in core?

Though this is trivial enough change, I think given recent Electron's design change makes this worthwhile.

From Electron@5, renderer process's nodeIntegration is being turned off by default (electron/electron#16235). This means in plain renderer process context, application code cannot access node / electron api directly. With this option turned off, recommended way is setup preload script to expose native functionality and let main renderer process only access those exposed api instead.

This means,

1. preload script now becomes near de-facto initialization logic for most electron application
2. loading time of preload script will be matter, cause time to load preload script will block main page loading
3. especially 2 will be important as now preload script have to load most nodejs side function logic for main pages

and supporting async chunk loading will provide the amount of performance improvement over. Having webpack core expose specified target for preload and encouraging to use async chunk loading for preload can help easier optimization of preload script based application design pattern for electron applications.

Webpack's target config itself allows to specify function to override custom target, but so far I couldn't find way to inherit existing config to override few options only. Still, there is a possibility I may not fully aware around webpack config so it can be achieved trivially without expanding target list. Opened PR since change's trivial enough, can be closed easily in that case.

Did you add tests for your changes?
Not yet. I believe there are high chance this will not be accepted in core and would like to discuss feasiblity before shape PR further.

Does this PR introduce a breaking change?
No.

What needs to be documented once your changes are merged?
Webpack documentation around options.target needs to include new target.

[webpack-bot]

For maintainers only:

• This need to be documented (issue in webpack/webpack.js.org will be filed when merged)

[webpack-bot]

Thank you for your pull request! The most important CI builds succeeded, we’ll review the pull request soon.

[webpack-bot]

It looks like this Pull Request doesn't include enough test cases (based on Code Coverage analysis of the PR diff).

A PR need to be covered by tests if you add a new feature (we want to make sure that your feature is working) or if you fix a bug (we want to make sure that we don't run into a regression in future).

@kwonoj Please check if this is appliable to your PR and if you can add more test cases.

Read the test readme for details how to write test cases.

[sokra]

Thanks