Bump esbuild from 0.16.8 to 0.16.13

[dependabot[bot]]

Bumps esbuild from 0.16.8 to 0.16.13.

Release notes

Sourced from esbuild's releases.

v0.16.13

• 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:

  • https://esbuild.github.io/analyze/

  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 metafile

  The 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 the path 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.

v0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
      Bundle: true,
      Loader: map[string]api.Loader{"": api.LoaderCSS},
    

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.16.13

• 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:

  • https://esbuild.github.io/analyze/

  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 metafile

  The 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 the path 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.

0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
    

... (truncated)

Commits

• 0db0b46 publish 0.16.13 to npm
• eda632d mention the bundle analyzer in the release notes
• 9234378 add the original field to the metafile
• d59ca10 feat: add markdown to guessed mime types (#2784)
• 59fd941 add a custom error message for #2783
• 6837c35 enable source maps for the json loader
• 16e77e7 fix test flake in watchMetafile
• 78a9be4 always use a plugin for post-build actions
• e4f32bb watch mode: print metafile analysis after rebuilds
• 867ef14 test coverage for: Cannot use "watch" with "serve"
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot[bot]]

Superseded by #174.