v0.15.10
-
Add support for node's "pattern trailers" syntax (#2569)
After esbuild implemented node's
exports
feature inpackage.json
, node changed the feature to also allow text after*
wildcards in patterns. Previously the*
was required to be at the end of the pattern. It lets you do something like this:{ "exports": { "./features/*": "./features/*.js", "./features/*.js": "./features/*.js" } }
With this release, esbuild now supports these types of patterns too.
-
Fix subpath imports with Yarn PnP (#2545)
Node has a little-used feature called subpath imports which are package-internal imports that start with
#
and that go through theimports
map inpackage.json
. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case. -
Link from JS to CSS in the metafile (#1861, #2565)
When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if
app.ts
imports some CSS files and you bundle it, esbuild will give youapp.js
andapp.css
. You would then add both<script src="app.js"></script>
and<link href="app.css" rel="stylesheet">
to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript intoapp.js
that downloads and includesapp.css
because it means the browser can download and parse both the CSS and the JS in parallel (and potentially apply the CSS before the JS has even finished downloading).However, sometimes it's difficult to generate the
<link>
tag. One case is when you've added[hash]
to the entry names setting to include a content hash in the file name. Then the file name will look something likeapp-GX7G2SBE.css
and may change across subsequent builds. You can tell esbuild to generate build metadata using themetafile
API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via theentryPoint
property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.This release adds the
cssBundle
property to the metafile to make this easier. It's present on the metadata for the generated JS bundle and points to the associated CSS bundle. So to generate the HTML tags for a given JS entry point, you first find the output file with theentryPoint
you are looking for (and put that in a<script>
tag), then check for thecssBundle
property to find the associated CSS bundle (and put that in a<link>
tag).One thing to note is that there is deliberately no
jsBundle
property mapping the other way because it's not a 1:1 relationship. Two JS bundles can share the same CSS bundle in the case where the associated CSS bundles have the same name and content. In that case there would be no one value for a hypotheticaljsBundle
property to have.