chore(deps): update dependency esbuild to v0.14.14 #1446

renovate · 2022-01-25T23:02:36Z

renovate commented

2022-01-25 23:02:36 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.14.13` -> `0.14.14`

Release Notes

evanw/esbuild

`v0.14.14`

Compare Source

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 the file loader. Importing a file with the file 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 the file 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 in package.json maps package subpaths to file paths. The mapping can be conditional, which lets it vary in different situations. For example, you can have an import condition that applies when the subpath originated from a JS import statement, and a require 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 situation some-pkg does not originate from either a JS import statement or a JS require call. Previously esbuild just didn't apply the import or require conditions. But that could result in path resolution failure if the package doesn't provide a back-up default condition, as is the case with the is-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 */
@&#8203;keyframes x { . }
@&#8203;keyframes y { 1% { a: b; } }

/* Old output (with --minify) */
@&#8203;keyframes x{y{1% {a: b;}}}

/* New output (with --minify) */
@&#8203;keyframes x{.}@&#8203;keyframes y{1%{a:b}}
```

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box.

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.14.13` -> `0.14.14`](https://renovatebot.com/diffs/npm/esbuild/0.14.13/0.14.14) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.14`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01414) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.13...v0.14.14) - Fix bug with filename hashes and the `file` loader ([#1957](https://github.com/evanw/esbuild/issues/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 the `file` loader. Importing a file with the `file` 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 the `file` 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](https://github.com/evanw/esbuild/issues/1956)) The `exports` field in `package.json` maps package subpaths to file paths. The mapping can be conditional, which lets it vary in different situations. For example, you can have an `import` condition that applies when the subpath originated from a JS import statement, and a `require` 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 situation `some-pkg` does not originate from either a JS import statement or a JS require call. Previously esbuild just didn't apply the `import` or `require` conditions. But that could result in path resolution failure if the package doesn't provide a back-up `default` condition, as is the case with the `is-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](https://github.com/evanw/esbuild/issues/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: ```css /* 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}} ``` </details> --- ### Configuration 📅 **Schedule**: At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovate added the

dependencies

label 2022-01-25 23:02:36 +00:00

renovate added 1 commit 2022-01-25 23:02:37 +00:00

continuous-integration/drone/pr Build is passing Details

b1fa3b2f8f chore(deps): update dependency esbuild to v0.14.14

frederick commented

2022-01-25 23:06:32 +00:00

Hi renovate!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://1446-renovateesbuild-0.x--vikunja-frontend-preview.netlify.app

You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.

Have a nice day!

Beep boop, I'm a bot.

Hi renovate! Thank you for creating a PR! I've deployed the changes of this PR on a preview environment under this URL: https://1446-renovateesbuild-0.x--vikunja-frontend-preview.netlify.app You can use this url to view the changes live and test them out. You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/. Have a nice day! > Beep boop, I'm a bot.

konrad merged commit e0141f4a38 into main

2022-01-26 07:12:23 +00:00

konrad deleted branch renovate/esbuild-0.x

2022-01-26 07:12:24 +00:00

konrad referenced this issue from a commit

2022-01-26 07:12:24 +00:00

chore(deps): update dependency esbuild to v0.14.14 (#1446)

This repo is archived. You cannot comment on pull requests.

No reviewers