Maarten Lakerveld
92599a8803
* Raise legacy browser floors to Chrome 67 and Safari/iOS 15
Every supported browser now has BigInt, which cannot be transpiled.
Chrome 67 keeps Fire tablets on Amazon WebView 70+ (Fire OS 5.6.4+ on
the 2017 models, Fire OS 6.3.1.2+, Fire OS 7) and the Chromecast 1st gen
(Chrome 70); it drops WebView 59 builds (Fire OS 5 on the 2015 and 2016
models, Fire OS 6.3.0.1). iOS/Safari 15 drops the iOS 12 devices (iPad
Air 1 / mini 2 / mini 3, iPhone 5s / 6 / 6 Plus); no Apple device ends on
iOS 13 or 14, so 15 costs the same devices as 13 or 14 would. The Chrome
floor, not Safari, decides what the legacy build transpiles.
Terser legacy ceiling goes to ecma 2019, supportsVectorMaps() no longer
feature-detects BigInt, and bundle-budget.json is re-seeded from a
clean build at dev 45ee91aed2 (legacy app -6.4%, core -15.3%).
* Drop workarounds for browsers below the new legacy floor
With Chrome 67 / Safari 15 as the floor, every supported browser has
ResizeObserver, Element.getAttributeNames, IntersectionObserver,
AbortController, an unprefixed AudioContext, PointerEvent and a
MediaQueryList that is an EventTarget, and iOS has ignored
-webkit-overflow-scrolling since 13. Remove the polyfills, runtime
gates and prefixed fallbacks that only existed for the old floor, and
switch MediaQueryList listeners to addEventListener("change").
* Pin the legacy floor at Safari/iOS 15.4 and Firefox 98
Native <dialog>, which ha-drawer, the popovers and wa-dialog rely on,
landed in Safari 15.4 and Firefox 98. Pinning there keeps the stated
floor honest and costs no device: every iOS 15 device updates to 15.8,
Catalina gets Safari 15.6.1, and Firefox below 98 is not supported by
Mozilla anyway.
* Tell browsers below the legacy floor why nothing loads
A browser that cannot parse the legacy bundles used to sit on the launch
screen forever with no explanation. Probe BigInt, the feature that sets
the Chrome floor, in the inline legacy script and write a message into
the launch-screen info box instead of loading bundles that will not run.
Bundling Home Assistant Frontend
The Home Assistant build pipeline contains various steps to prepare a build.
- Generating icon files to be included
- Generating translation files to be included
- Converting TypeScript, CSS and JSON files to JavaScript
- Bundling
- Minifying the files
- Generating the HTML entrypoint files
- Generating the service worker
- Compressing the files
Converting files
Currently in Home Assistant we use a bundler to convert TypeScript, CSS and JSON files to JavaScript files that the browser understands.
We currently rely on Webpack. Both of these programs bundle the converted files in both production and development.
For development, bundling is optional. We just want to get the right files in the browser.
Responsibilities of the converter during development:
- Convert TypeScript to JavaScript
- Convert CSS to JavaScript that sets the content as the default export
- Convert JSON to JavaScript that sets the content as the default export
- Make sure import, dynamic import and web worker references work
- Add extensions where missing
- Resolve absolute package imports
- Filter out specific imports/packages
- Replace constants with values
In production, the following responsibilities are added:
- Minify HTML
- Bundle multiple imports so that the browser can fetch less files
- Generate a second version that is compatible with older browsers (legacy build)
Configuration for all these steps are specified in bundle.js.
Auditing browser support changes
node build-scripts/list-plugins-and-polyfills.js prints, per browserslist
environment (modern/legacy), the Babel transforms preset-env enables and the
Core-JS polyfills that may be injected — as collapsible markdown ready to
paste into a PR. Use it to show the bundle impact when changing
.browserslistrc or the Babel configuration.