-
Publish a new bundle visualization tool
While esbuild provides bundle metadata via the
--metafile
flag, previously esbuild left analysis of it completely up to third-party tools (well, outside of the rudimentary--analyze
flag). However, the esbuild website now has a built-in bundle visualization tool:You can pass
--metafile
to esbuild to output bundle metadata, then upload that JSON file to this tool to visualize your bundle. This is helpful for answering questions such as:- Which packages are included in my bundle?
- How did a specific file get included?
- How small did a specific file compress to?
- Was a specific file tree-shaken or not?
I'm publishing this tool because I think esbuild should provide some answer to "how do I visualize my bundle" without requiring people to reach for third-party tools. At the moment the tool offers two types of visualizations: a radial "sunburst chart" and a linear "flame chart". They serve slightly different but overlapping use cases (e.g. the sunburst chart is more keyboard-accessible while the flame chart is easier with the mouse). This tool may continue to evolve over time.
-
Fix
--metafile
and--mangle-cache
with--watch
(#1357)The CLI calls the Go API and then also writes out the metafile and/or mangle cache JSON files if those features are enabled. This extra step is necessary because these files are returned by the Go API as in-memory strings. However, this extra step accidentally didn't happen for all builds after the initial build when watch mode was enabled. This behavior used to work but it was broken in version 0.14.18 by the introduction of the mangle cache feature. This release fixes the combination of these features, so the metafile and mangle cache features should now work with watch mode. This behavior was only broken for the CLI, not for the JS or Go APIs.
-
Add an
original
field to the metafileThe metadata file JSON now has an additional field: each import in an input file now contains the pre-resolved path in the
original
field in addition to the post-resolved path in thepath
field. This means it's now possible to run certain additional analysis over your bundle. For example, you should be able to use this to detect when the same package subpath is represented multiple times in the bundle, either because multiple versions of a package were bundled or because a package is experiencing the dual-package hazard.