search

arimgibson / Deadname-Remover

An easy to use Firefox and Chrome plugin to automatically remove and replace deadnames
MIT License
120 stars 30 forks source link

Bump esbuild from 0.8.54 to 0.14.14 #479

Closed dependabot[bot] closed 2 years ago

dependabot[bot] commented 2 years ago

Bumps esbuild from 0.8.54 to 0.14.14.

Release notes

Sourced from esbuild's releases.

v0.14.14

  • 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 */
@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}}

v0.14.13

  • Be more consistent about external paths (#619)

    The rules for marking paths as external using --external: grew over time as more special-cases were added. This release reworks the internal representation to be more straightforward and robust. A side effect is that wildcard patterns can now match post-resolve paths in addition to pre-resolve paths. Specifically you can now do --external:./node_modules/* to mark all files in the ./node_modules/ directory as external.

    This is the updated logic:

    • Before path resolution begins, import paths are checked against everything passed via an --external: flag. In addition, if something looks like a package path (i.e. doesn't start with / or ./ or ../), import paths are checked to see if they have that package path as a path prefix (so --external:@foo/bar matches the import path @foo/bar/baz).

    • After path resolution ends, the absolute paths are checked against everything passed via --external: that doesn't look like a package path (i.e. that starts with / or ./ or ../). But before checking, the pattern is transformed to be relative to the current working directory.

  • Attempt to explain why esbuild can't run (#1819)

    People sometimes try to install esbuild on one OS and then copy the node_modules directory over to another OS without reinstalling. This works with JavaScript code but doesn't work with esbuild because esbuild is a native binary executable. This release attempts to offer a helpful error message when this happens. It looks like this:

    $ ./node_modules/.bin/esbuild
./node_modules/esbuild/bin/esbuild:106
          throw new Error(`
          ^

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.14

  • 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 */
@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}}

0.14.13

  • Be more consistent about external paths (#619)

    The rules for marking paths as external using --external: grew over time as more special-cases were added. This release reworks the internal representation to be more straightforward and robust. A side effect is that wildcard patterns can now match post-resolve paths in addition to pre-resolve paths. Specifically you can now do --external:./node_modules/* to mark all files in the ./node_modules/ directory as external.

    This is the updated logic:

    • Before path resolution begins, import paths are checked against everything passed via an --external: flag. In addition, if something looks like a package path (i.e. doesn't start with / or ./ or ../), import paths are checked to see if they have that package path as a path prefix (so --external:@foo/bar matches the import path @foo/bar/baz).

    • After path resolution ends, the absolute paths are checked against everything passed via --external: that doesn't look like a package path (i.e. that starts with / or ./ or ../). But before checking, the pattern is transformed to be relative to the current working directory.

  • Attempt to explain why esbuild can't run (#1819)

    People sometimes try to install esbuild on one OS and then copy the node_modules directory over to another OS without reinstalling. This works with JavaScript code but doesn't work with esbuild because esbuild is a native binary executable. This release attempts to offer a helpful error message when this happens. It looks like this:

    $ ./node_modules/.bin/esbuild
./node_modules/esbuild/bin/esbuild:106
          throw new Error(`

... (truncated)

Commits


Dependabot compatibility score

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)
dependabot[bot] commented 2 years ago

Superseded by #480.