Important points about webpack configuration
The ForkTsCheckerWebpackPlugin async is false so that build process returns non-zero code if the typescript type check fails;
useful for continuous integration.
new ForkTsCheckerWebpackPlugin({
async: false,
watch: localPath('src'),
tslint: true,
})
Although webpack 4 provides excellent optimization.splitChunks option, it cannot be enabled for extension development.
Chunks generated by the splitChunks communicate through the shared window variable.
However, each browser content script lives in a sandbox (see here);
it can access window variable but most probably each such window instance is just a clone of the DOM window.
The only real way content scripts can interact is through the actual DOM (or a kind fo WEB API messages).
The manual division into two entry points is decent but surely there is room for improvement.
If a content script CSS tries to load a static file, the the URL is interpreted relative to the tab URL,
not the browser extension URL (so we end up with e.g. stackoverflow.com/assets/extension_icon.png instead of
chrome-extension://XYZ/assets/extension_icon.png.
Some solutions have been proposed here.
However, they make the code inflexible --
they cannot be used in a simple client app anymore, as existence of chrome browser extension is assumed.
We manually set the browser extension key (more here), so we know the app key at runtime and can explicitly define the address where static files should be searched for:
publicPath: chrome-extension://${KEY}/
(where we ourselves have devised the KEY)
The production key is provided by Chrome on app registration.