target_web packages should be built as browser-agnostic ES modules

[afharo]

Summary

The Bazel step building target_web now uses the new preset @kbn/babel-preset/web_preset. The main difference with @kbn/babel-preset/webpack_preset is that it initially emits browser-agnostic ES modules.

Motivation

In Kibana, when building the packages' target_web version, the transpiled code is not the final bundle we ship to the browsers. The final bundle is built at a later stage by Webpack in @kbn/optimizer.

For this reason, building a browserlist-compiled version of target_web creates a larger package output that will be concatenated to the code before Webpack applies the browserlist version of the final bundle. IMO, we don't need that 2-level browserlist-fy process and we can rely on the final Webpack step to do that.

Related to #88678

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 9c0b1cb
• Storybooks Preview
• Webpack Bundle Analyzer

Test Failures

• [job] [logs] Default CI Group #4 / lens app lens drag and drop tests basic drag and drop should combine breakdown dimension with the horizontal one
• [job] [logs] Default CI Group #4 / lens app "after all" hook in "lens app"

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
apm	2.8MB	2.8MB	-823.0B
canvas	1.0MB	1.0MB	-2.3KB
charts	78.7KB	77.0KB	-1.6KB
cloudSecurityPosture	409.2KB	405.8KB	-3.4KB
controls	437.7KB	434.0KB	-3.7KB
dashboard	301.4KB	297.3KB	-4.1KB
data	15.1KB	15.1KB	-5.0B
dataViewEditor	170.1KB	168.9KB	-1.3KB
dataViewManagement	124.0KB	120.6KB	-3.4KB
dataVisualizer	539.6KB	536.3KB	-3.4KB
discover	407.6KB	403.2KB	-4.3KB
expressionHeatmap	80.7KB	79.0KB	-1.6KB
fleet	693.3KB	691.0KB	-2.3KB
graph	476.8KB	474.4KB	-2.4KB
infra	1002.7KB	999.4KB	-3.2KB
inputControlVis	77.6KB	75.4KB	-2.2KB
lens	1.1MB	1.1MB	-4.8KB
lists	147.7KB	137.6KB	-10.2KB
maps	2.5MB	2.5MB	-25.0B
ml	3.3MB	3.3MB	-3.3KB
monitoring	471.1KB	468.8KB	-2.3KB
observability	427.8KB	427.8KB	+25.0B
presentationUtil	136.8KB	136.8KB	-70.0B
securitySolution	4.8MB	4.8MB	-16.8KB
spaces	285.8KB	284.5KB	-1.3KB
stackAlerts	202.8KB	200.5KB	-2.4KB
synthetics	787.4KB	784.8KB	-2.5KB
transform	374.8KB	371.4KB	-3.3KB
unifiedSearch	116.2KB	116.2KB	-6.0B
upgradeAssistant	179.2KB	177.0KB	-2.2KB
ux	170.2KB	169.4KB	-750.0B
visTypeTimelion	120.9KB	117.6KB	-3.3KB
visTypeVega	1.7MB	1.7MB	-3.5KB
visualizations	165.6KB	163.3KB	-2.3KB
total			-99.1KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
charts	46.2KB	46.1KB	-77.0B
dashboardEnhanced	41.6KB	39.4KB	-2.2KB
data	410.9KB	406.8KB	-4.1KB
kbnUiSharedDeps-srcJs	3.8MB	3.7MB	-6.4KB
maps	70.1KB	67.8KB	-2.3KB
observability	91.9KB	89.6KB	-2.3KB
osquery	16.2KB	16.2KB	-10.0B
securitySolution	248.0KB	243.6KB	-4.4KB
timelines	275.9KB	272.3KB	-3.6KB
unifiedSearch	87.8KB	84.7KB	-3.1KB
total			-28.5KB

History

• 💔 Build #40456 failed 6ed656cbbe494d449e6952b422754aa1dab4b091
• 💚 Build #40350 succeeded 56ce0a7be25bafcd9f29febdedfe96d9328cf023
• 💔 Build #40261 failed 193f434307e5105d6733aed46c291e75b145a041

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[afharo]

IMO, we don't need that 2-level browserlist-fy process and we can rely on the final Webpack step to do that.

Closing this PR as @spalger confirmed that the above assumption is not true Webpack doesn't apply transforms to support new syntax/features in older browsers, babel does that, and I'm pretty sure removing that from packages is what decreased the bundle sizes