-
Fix bug with filename hashes and the
file
loader (#1957)This release fixes a bug where if a file name template has the
[hash]
placeholder (either--entry-names=
or--chunk-names=
), the hash that esbuild generates didn't include the content of the string generated by thefile
loader. Importing a file with thefile
loader causes the imported file to be copied to the output directory and causes the imported value to be the relative path from the output JS file to that copied file. This bug meant that if the--asset-names=
setting also contained[hash]
and the file loaded with thefile
loader was changed, the hash in the copied file name would change but the hash of the JS file would not change, which could potentially result in a stale JS file being loaded. Now the hash of the JS file will be changed too which fixes the reload issue. -
Prefer the
import
condition for entry points (#1956)The
exports
field inpackage.json
maps package subpaths to file paths. The mapping can be conditional, which lets it vary in different situations. For example, you can have animport
condition that applies when the subpath originated from a JS import statement, and arequire
condition that applies when the subpath originated from a JS require call. These are supposed to be mutually exclusive according to the specification: https://nodejs.org/api/packages.html#conditional-exports.However, there's a situation with esbuild where it's not immediately obvious which one should be applied: when a package name is specified as an entry point. For example, this can happen if you do
esbuild --bundle some-pkg
on the command line. In this situationsome-pkg
does not originate from either a JS import statement or a JS require call. Previously esbuild just didn't apply theimport
orrequire
conditions. But that could result in path resolution failure if the package doesn't provide a back-updefault
condition, as is the case with theis-plain-object
package.Starting with this release, esbuild will now use the
import
condition in this case. This appears to be how Webpack and Rollup handle this situation so this change makes esbuild consistent with other tools in the ecosystem. Parcel (the other major bundler) just doesn't handle this case at all so esbuild's behavior is not at odds with Parcel's behavior here. -
Make parsing of invalid
@keyframes
rules more robust (#1959)This improves esbuild's parsing of certain malformed
@keyframes
rules to avoid them affecting the following rule. This fix only affects invalid CSS files, and does not change any behavior for files containing valid CSS. Here's an example of the fix:/* Original code */ @keyframes x { . } @keyframes y { 1% { a: b; } } /* Old output (with --minify) */ @keyframes x{y{1% {a: b;}}} /* New output (with --minify) */ @keyframes x{.}@keyframes y{1%{a:b}}