dev: webpack bundle sizes

[danielweck]

Perhaps there is some room for improvement ...
(removing Moment locales would decrease the bundle size, for example)

[danielweck]

PS: note that bundle compression/optimization is enabled only to remove whitespaces, not to mangle class/function names, and not to perform any other smart processing of the Javascript AST.

See:

thorium-reader/webpack.config.main.js

Lines 203 to 225 in bee2de1

	config.optimization =
	{
	...(config.optimization || {}),
	minimize: true,
	minimizer: [
	new TerserPlugin({
	extractComments: false,
	exclude: /MathJax/,
	terserOptions: {
	compress: false,
	mangle: false,
	output: {
	comments: false,
	},
	// node-fetch v2.x (fixed in 3.x https://github.com/node-fetch/node-fetch/pull/673 )
	// keep_fnames: /AbortSignal/,
	},
	}),
	],
	};
	// {
	// minimize: false,
	// };

thorium-reader/webpack.config.preload.js

Lines 28 to 48 in bee2de1

	config.optimization =
	{
	...(config.optimization || {}),
	minimize: true,
	minimizer: [
	new TerserPlugin({
	extractComments: false,
	exclude: /MathJax/,
	terserOptions: {
	compress: false,
	mangle: false,
	output: {
	comments: false,
	},
	},
	}),
	],
	};
	// {
	// minimize: false,
	// };

thorium-reader/webpack.config.renderer-library.js

Lines 274 to 294 in bee2de1

	config.optimization =
	{
	...(config.optimization || {}),
	minimize: true,
	minimizer: [
	new TerserPlugin({
	extractComments: false,
	exclude: /MathJax/,
	terserOptions: {
	compress: false,
	mangle: false,
	output: {
	comments: false,
	},
	},
	}),
	],
	};
	// {
	// minimize: false,
	// };

thorium-reader/webpack.config.renderer-pdf.js

Lines 270 to 290 in bee2de1

	config.optimization =
	{
	...(config.optimization || {}),
	minimize: true,
	minimizer: [
	new TerserPlugin({
	extractComments: false,
	exclude: /MathJax/,
	terserOptions: {
	compress: false,
	mangle: false,
	output: {
	comments: false,
	},
	},
	}),
	],
	};
	// {
	// minimize: false,
	// };

thorium-reader/webpack.config.renderer-reader.js

Lines 262 to 282 in bee2de1

	config.optimization =
	{
	...(config.optimization || {}),
	minimize: true,
	minimizer: [
	new TerserPlugin({
	extractComments: false,
	exclude: /MathJax/,
	terserOptions: {
	compress: false,
	mangle: false,
	output: {
	comments: false,
	},
	},
	}),
	],
	};
	// {
	// minimize: false,
	// };

[danielweck]

This commit introduces npm run bundle-stats to generate the bundle contents images:
51c1baf

[MattiJarvinen]

I'd advice switching from momentjs to date-fns, you can then drop out all momentjs localizations, if you need all the localizations then there's nothing you can do there.

There seems to be quite a lot of lodash... depending on your browser targets most of the lodash stuff is easy to accomplish with modern JS or just tweak your imports to tree shakeable. You might find some help on that here https://www.azavea.com/blog/2019/03/07/lessons-on-tree-shaking-lodash/. Especially the tree shaking part could help to reduce that quite a bit.

Tree-shaking is syntax-sensitive. To enable tree-shaking in lodash, you have to import functions using syntax like import foo from 'lodash/foo'. import { foo } from 'lodash' will not tree-shake, nor will, obviously, import _ from 'lodash'. Support for this syntax was implemented in Lodash v4.

Anyhow for a packaged / desktop application this isn't so much of an issue, but a good thing to keep your eyes on.

[danielweck]

Thank you for your input. Some of the heavy dependencies are transitive, so we might need to dig deeper to find the culprits.

[danielweck]

The Javascript bundles generated by WebPack for the "reader" and "library" renderer Electron processes include code that is shared with / common to the "main" process bundle. Therefore, there is an opportunity to factor out some dependencies by placing them into node_modules (i.e. still located inside the Electron ASAR, but inside an externalised node_modules folder within the ASAR virtual filesystem). This is technically doable because at the moment the "reader" and "library" renderer Electron processes are "Node enabled", which means that the NodeJS dependency resolver can be used instead of relying solely on WebPack's own bundler / resolver. A simple way to implement this would be to include additional NPM dependencies in WebPack's externals directive. The net gain would be x-amount of bytes in the main and renderer processes JS bundles ... to be determined empirically (i.e. by implementing the WebPack change, and comparing the size of generated bundles).
Note that preferably ("eventually"?) all renderer Electron processes should have NodeJS disabled (aka "node integration"), and rely purely on postMessage/WebSocket/HTTP etc. rather than IPC Electron-specific APIs. I'm not sure how extensive the refactoring would need to be ... probably quite disruptive and prone to introduce regression bugs.

[danielweck]

PS: when "node integration" is disabled in renderer processes, standard OpenWebPlatform APIs can be used (such as postMessage/WebSocket/HTTP), but there is probably a better alternative: preload. The reader and library BrowserWindows could implement a "communication bridge" in a preload script that would have high NodeJS privileges, including the capacity to resolve NodeJS packages and use Electron/Node APIs (such as the IPC layer).