evanw/esbuild v0.9.3

on GitHub

Fix path resolution with the exports field for scoped packages

This release fixes a bug where the exports field in package.json files was not being detected for scoped packages (i.e. packages of the form @scope/pkg-name instead of just pkg-name). The exports field should now be respected for these kinds of packages.

Improved error message in exports failure case

Node's new conditional exports feature can be non-intuitive and hard to use. Now that esbuild supports this feature (as of version 0.9.0), you can get into a situation where it's impossible to import a package if the package's exports field in its package.json file isn't configured correctly.

Previously the error message for this looked like this:

 > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
     1 │ import 'jotai'
       ╵        ~~~~~~~
   node_modules/jotai/package.json:16:13: note: The path "." is not exported by "jotai"
    16 │   "exports": {
       ╵              ^

With this release, the error message will now provide additional information about why the package cannot be imported:

 > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
     1 │ import 'jotai'
       ╵        ~~~~~~~
   node_modules/jotai/package.json:16:13: note: The path "." is not currently exported by package "jotai"
    16 │   "exports": {
       ╵              ^
   node_modules/jotai/package.json:18:9: note: None of the conditions provided ("module", "require", "types") match any of the currently active conditions ("browser", "default", "import")
    18 │     ".": {
       ╵          ^
   entry.js:1:7: note: Consider using a "require()" call to import this package
     1 │ import 'jotai'
       ╵        ~~~~~~~

In this case, one solution could be import this module using require() since this package provides an export for the require condition. Another solution could be to pass --conditions=module to esbuild since this package provides an export for the module condition (the types condition is likely not valid JavaScript code).

This problem occurs because this package doesn't provide an import path for ESM code using the import condition and also doesn't provide a fallback import path using the default condition.

Mention glob syntax in entry point error messages (#976)

In this release, including a * in the entry point path now causes the failure message to tell you that glob syntax must be expanded first before passing the paths to esbuild. People that hit this are usually converting an existing CLI command to a JavaScript API call and don't know that glob expansion is done by their shell instead of by esbuild. An appropriate fix is to use a library such as glob to expand the glob pattern first before passing the paths to esbuild.

Raise certain VM versions in the JavaScript feature compatibility table

JavaScript VM feature compatibility data is derived from this dataset: https://kangax.github.io/compat-table/. The scripts that process the dataset expand the data to include all VM versions that support a given feature (e.g. chrome44, chrome45, chrome46, ...) so esbuild takes the minimum observed version as the first version for which the feature is supported.

However, some features can have subtests that each check a different aspect of the feature. In this case the desired version is the minimum version within each individual subtest, but the maximum of those versions across all subtests (since esbuild should only use the feature if it works in all cases). Previously esbuild computed the minimum version across all subtests, but now esbuild computes the maximum version across all subtests. This means esbuild will now lower JavaScript syntax in more cases.

Mention the configured target environment in error messages (#975)

Using newer JavaScript syntax with an older target environment (e.g. chrome10) can cause a build error if esbuild doesn't support transforming that syntax such that it is compatible with that target environment. Previously the error message was generic but with this release, the target environment is called outp explicitly in the error message. This is helpful if esbuild is being wrapped by some other tool since the other tool can obscure what target environment is actually being passed to esbuild.

Fix an issue with Unicode and source maps

This release fixes a bug where non-ASCII content that ended up in an output file but that was not part of an input file could throw off source mappings. An example of this would be passing a string containing non-ASCII characters to the globalName setting with the minify setting active and the charset setting set to utf8. The conditions for this bug are fairly specific and unlikely to be hit, so it's unsurprising that this issue hasn't been discovered earlier. It's also unlikely that this issue affected real-world code.

The underlying cause is that while the meaning of column numbers in source maps is undefined in the specification, in practice most tools treat it as the number of UTF-16 code units from the start of the line. The bug happened because column increments for outside-of-file characters were incorrectly counted using byte offsets instead of UTF-16 code unit counts.