Bump esbuild from 0.15.9 to 0.15.10 #27

Closed

dependabot[bot] wants to merge 1 commit from dependabot/npm_and_yarn/esbuild-0.15.10 into master

dependabot[bot] commented

2022-10-03 05:27:11 +00:00

(Migrated from github.com)

Bumps esbuild from 0.15.9 to 0.15.10.

Release notes

Sourced from esbuild's releases.

v0.15.10
Add support for node's "pattern trailers" syntax (#2569)

After esbuild implemented node's exports feature in package.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 the imports map in package.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 you app.js and app.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 into app.js that downloads and includes app.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 like app-GX7G2SBE.css and may change across subsequent builds. You can tell esbuild to generate build metadata using the metafile API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the entryPoint 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 the entryPoint you are looking for (and put that in a <script> tag), then check for the cssBundle 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 hypothetical jsBundle property to have.

Changelog

Sourced from esbuild's changelog.

0.15.10
Add support for node's "pattern trailers" syntax (#2569)

After esbuild implemented node's exports feature in package.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 the imports map in package.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 you app.js and app.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 into app.js that downloads and includes app.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 like app-GX7G2SBE.css and may change across subsequent builds. You can tell esbuild to generate build metadata using the metafile API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the entryPoint 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 the entryPoint you are looking for (and put that in a <script> tag), then check for the cssBundle 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 hypothetical jsBundle property to have.

Commits

aaae34e publish 0.15.10 to npm
4bd03f3 fix #1861, fix #2565: add cssBundle to metafile
c55000d Fix subpath imports with Yarn PnP (#2547)
1bce251 fix transform tsconfigRaw type (#2568)
efd0af6 fix #2569: support node's "pattern trailer" syntax
23709e2 makefile: fix build validation bug
See full diff 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)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.15.9 to 0.15.10. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/releases">esbuild's releases</a>.</em></p> <blockquote> <h2>v0.15.10</h2> <ul> <li> <p>Add support for node's "pattern trailers" syntax (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2569">#2569</a>)</p> <p>After esbuild implemented node's <code>exports</code> feature in <code>package.json</code>, node changed the feature to also allow text after <code>*</code> wildcards in patterns. Previously the <code>*</code> was required to be at the end of the pattern. It lets you do something like this:</p> <pre lang="json"><code>{ "exports": { "./features/*": "./features/*.js", "./features/*.js": "./features/*.js" } } </code></pre> <p>With this release, esbuild now supports these types of patterns too.</p> </li> <li> <p>Fix subpath imports with Yarn PnP (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2545">#2545</a>)</p> <p>Node has a little-used feature called <a href="https://nodejs.org/api/packages.html#subpath-imports">subpath imports</a> which are package-internal imports that start with <code>#</code> and that go through the <code>imports</code> map in <code>package.json</code>. 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.</p> </li> <li> <p>Link from JS to CSS in the metafile (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/1861">#1861</a>, <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2565">#2565</a>)</p> <p>When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if <code>app.ts</code> imports some CSS files and you bundle it, esbuild will give you <code>app.js</code> and <code>app.css</code>. You would then add both <code><script src="app.js"></script></code> and <code><link href="app.css" rel="stylesheet"></code> to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript into <code>app.js</code> that downloads and includes <code>app.css</code> 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).</p> <p>However, sometimes it's difficult to generate the <code><link></code> tag. One case is when you've added <code>[hash]</code> to the <a href="https://esbuild.github.io/api/#entry-names">entry names</a> setting to include a content hash in the file name. Then the file name will look something like <code>app-GX7G2SBE.css</code> and may change across subsequent builds. You can tell esbuild to generate build metadata using the <code>metafile</code> API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the <code>entryPoint</code> property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.</p> <p>This release adds the <code>cssBundle</code> 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 the <code>entryPoint</code> you are looking for (and put that in a <code><script></code> tag), then check for the <code>cssBundle</code> property to find the associated CSS bundle (and put that in a <code><link></code> tag).</p> <p>One thing to note is that there is deliberately no <code>jsBundle</code> 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 hypothetical <code>jsBundle</code> property to have.</p> </li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">esbuild's changelog</a>.</em></p> <blockquote> <h2>0.15.10</h2> <ul> <li> <p>Add support for node's "pattern trailers" syntax (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2569">#2569</a>)</p> <p>After esbuild implemented node's <code>exports</code> feature in <code>package.json</code>, node changed the feature to also allow text after <code>*</code> wildcards in patterns. Previously the <code>*</code> was required to be at the end of the pattern. It lets you do something like this:</p> <pre lang="json"><code>{ "exports": { "./features/*": "./features/*.js", "./features/*.js": "./features/*.js" } } </code></pre> <p>With this release, esbuild now supports these types of patterns too.</p> </li> <li> <p>Fix subpath imports with Yarn PnP (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2545">#2545</a>)</p> <p>Node has a little-used feature called <a href="https://nodejs.org/api/packages.html#subpath-imports">subpath imports</a> which are package-internal imports that start with <code>#</code> and that go through the <code>imports</code> map in <code>package.json</code>. 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.</p> </li> <li> <p>Link from JS to CSS in the metafile (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/1861">#1861</a>, <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2565">#2565</a>)</p> <p>When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if <code>app.ts</code> imports some CSS files and you bundle it, esbuild will give you <code>app.js</code> and <code>app.css</code>. You would then add both <code><script src="app.js"></script></code> and <code><link href="app.css" rel="stylesheet"></code> to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript into <code>app.js</code> that downloads and includes <code>app.css</code> 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).</p> <p>However, sometimes it's difficult to generate the <code><link></code> tag. One case is when you've added <code>[hash]</code> to the <a href="https://esbuild.github.io/api/#entry-names">entry names</a> setting to include a content hash in the file name. Then the file name will look something like <code>app-GX7G2SBE.css</code> and may change across subsequent builds. You can tell esbuild to generate build metadata using the <code>metafile</code> API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the <code>entryPoint</code> property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.</p> <p>This release adds the <code>cssBundle</code> 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 the <code>entryPoint</code> you are looking for (and put that in a <code><script></code> tag), then check for the <code>cssBundle</code> property to find the associated CSS bundle (and put that in a <code><link></code> tag).</p> <p>One thing to note is that there is deliberately no <code>jsBundle</code> 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 hypothetical <code>jsBundle</code> property to have.</p> </li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/evanw/esbuild/commit/aaae34eb60632f9945c96379fb3fd22580815e9c"><code>aaae34e</code></a> publish 0.15.10 to npm</li> <li><a href="https://github.com/evanw/esbuild/commit/4bd03f3d1426acd58db7bed999c34687825d4251"><code>4bd03f3</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/1861">#1861</a>, fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2565">#2565</a>: add <code>cssBundle</code> to metafile</li> <li><a href="https://github.com/evanw/esbuild/commit/c55000ddab88389813cc7dac7db6e50adf5ad574"><code>c55000d</code></a> Fix subpath imports with Yarn PnP (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2547">#2547</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/1bce251e80bdf93a912bc2bf98b7f1f4586724a7"><code>1bce251</code></a> fix transform tsconfigRaw type (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2568">#2568</a>)</li> <li><a href="https://github.com/evanw/esbuild/commit/efd0af66bfb06eb3f46e961aa35920eb90df602d"><code>efd0af6</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2569">#2569</a>: support node's "pattern trailer" syntax</li> <li><a href="https://github.com/evanw/esbuild/commit/23709e2c9f15c643e6c707d9cc77a25e5d9147cf"><code>23709e2</code></a> makefile: fix build validation bug</li> <li>See full diff in <a href="https://github.com/evanw/esbuild/compare/v0.15.9...v0.15.10">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=esbuild&package-manager=npm_and_yarn&previous-version=0.15.9&new-version=0.15.10)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> 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) </details>

dependabot[bot] commented

2022-10-03 08:58:32 +00:00

(Migrated from github.com)

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it.