feat(web): downcompile helper treeshaking 🧩

[jahorton]

From #8904:

That said, after further experimentation, I believe I've figured out how to use esbuild plugins to handle tslib treeshaking ourselves...

esbuild isn't able to figure it out on its own, as we're having it bundle ES5 JS files that result from our TS compilation, so we have to help it along. We can utilize esbuild's plugin feature as an "in" to perform treeshaking of tslib's importable helper definitions.

I might have invested a bit much into it, given the limited savings this affords us, but I've aimed to make the treeshaker reasonably maintainable.

• If we ever update tslib versions and new helpers get added, build warnings will be logged about potential, as-of-yet-unverified helpers that could be added to the treeshaking detection system.
  • I opted for this, rather than have the detector assume all pattern-conforming names in tslib.js are treeshakable.
  • Said assumption fortunately holds for now... but we aren't in the position to enforce it, as we're not its maintainers.
• While not perfect, the plugin tries to only treeshake function definitions that it can confidently handle. It'll abort treeshaking for a helper and report warnings if a pattern doesn't match expectations.
• It will also abort and report build errors if something goes seriously wrong... like trying to 'treeshake' past the end of a file.

These reports are integrated within esbuild's output logs by use of the proper plugin return types & message forwarding. It'll even highlight the helper and its location within the main tslib.js file that's presenting a problem within the logged message, which gets hyperlinked in build logs (when viewed within VS Code's terminal, at least).

This saves us maybe another 8.5 KB in total after #8904; it's not that much, but it is something, at least. (That is over 33% of the increase noted by the check/web/filesize check reported for #8904.) And this optimization work was absolutely necessary for tslib to save us anything at all within the lm-worker due to its comparatively minimal use of downcompile-helpers.

@keymanapp-test-bot skip

[keymanapp-test-bot]

User Test Results

Test specification and instructions

User tests are not required

Test Artifacts

• Android
  • Keyman for Android apk
  • FirstVoices for Android 16.0 apk
  • FirstVoices Keyboards for Android apk
  • KeyboardHarness apk
  • Keyman for Android 16.0 apk
  • KMSample1 apk
  • KMSample2 apk
• iOS
  • Keyman for iOS (simulator image)
  • FirstVoices Keyboards for iOS (simulator image)
  • TestFlight internal PR build version - 17.0.119 (0.8964.8647)
• Web
  • KeymanWeb Test Home
• Windows
  • Keyman for Windows
  • FirstVoices Keyboards for Windows
  • Text Editor (32 bit)
  • Text Editor (64 bit)

[jahorton]

Report from my local build with the current state of this PR:

❌ Oh dear! keymanweb.js is 14,198 bytes (3%) larger than 17.0.120, now 407,223 bytes

Compared against #8904:

❌ Oh dear! keymanweb.js is 23041 bytes (5%) larger than 17.0.120, now 416066 bytes

[mcdurdin]

LGTM. I wonder if this is something we could submit upstream to esbuild or typescript/tslib maintainers? It may be that they would be willing to take this on since it is a nice perf optimization for many common build chains

[jahorton]

LGTM. I wonder if this is something we could submit upstream to esbuild or typescript/tslib maintainers? It may be that they would be willing to take this on since it is a nice perf optimization for many common build chains

I've linked this and its predecessor to the most relevant esbuild issue I could find: evanw/esbuild#2296.

For tslib, I've posted something similar at microsoft/tslib#173. They seem to be generally resistant to changing the importable scripts and their setup due to reasons documented at microsoft/tslib#180, so I'm hesistant to try contributing a 'fix' - as I'd likely break other patterns that they're concerned about.