webstone-plugins chore(deps): update dependency esbuild to ^0.15.11

chore(deps): update dependency esbuild to ^0.15.11

Open renovate[bot] opened this issue 2 years ago • 1 comments

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`^0.15.7` -> `^0.15.11`

Release Notes

evanw/esbuild

`v0.15.11`

Compare Source

Fix various edge cases regarding template tags and this (#2610)

This release fixes some bugs where the value of this wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:

async function test() {
  class Foo { foo() { return this } }
  class Bar extends Foo {
    a = async () => super.foo``
    b = async () => super['foo']``
    c = async (foo) => super[foo]``
  }
  function foo() { return this }
  const obj = { foo }
  const bar = new Bar
  console.log(
    (await bar.a()) === bar,
    (await bar.b()) === bar,
    (await bar.c('foo')) === bar,
    { foo }.foo``.foo === foo,
    (true && obj.foo)`` !== obj,
    (false || obj.foo)`` !== obj,
    (null ?? obj.foo)`` !== obj,
  )
}
test()

Each edge case in the code above previously incorrectly printed false when run through esbuild with --minify --target=es6 but now correctly prints true. These edge cases are unlikely to have affected real-world code.

`v0.15.10`

Compare Source

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.

`v0.15.9`

Compare Source

Fix an obscure npm package installation issue with --omit=optional (#2558)

The previous release introduced a regression with npm install esbuild --omit=optional where the file node_modules/.bin/esbuild would no longer be present after installation. That could cause any package scripts which used the esbuild command to no longer work. This release fixes the regression so node_modules/.bin/esbuild should now be present again after installation. This regression only affected people installing esbuild using npm with either the --omit=optional or --no-optional flag, which is a somewhat unusual situation.

More details:

The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the esbuild-wasm package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both the esbuild package and the esbuild-wasm package provide a binary called esbuild and it turns out that adding esbuild-wasm as a nested dependency of the esbuild package (specifically esbuild optionally depends on @esbuild/android-arm which depends on esbuild-wasm) caused npm to be confused about what node_modules/.bin/esbuild is supposed to be.

It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if --omit=optional is present, npm attempts to uninstall the esbuild-wasm nested dependency at the end of npm install (even though the esbuild-wasm package was never installed due to --omit=optional). This uninstallation causes node_modules/.bin/esbuild to be deleted.

After doing a full investigation, I discovered that npm's handling of the .bin directory is deliberately very brittle. When multiple packages in the dependency tree put something in .bin with the same name, the end result is non-deterministic/random. What you get in .bin might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in .bin with the same name. So this was fixed by making the @esbuild/android-arm and esbuild-android-64 packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in .bin.

`v0.15.8`

Compare Source

Fix JSX name collision edge case (#2534)

Code generated by esbuild could have a name collision in the following edge case:
- The JSX transformation mode is set to automatic, which causes import statements to be inserted
- An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react
- Another import uses a name that ends with react such as @remix-run/react
- The output format has been set to CommonJS so that import statements are converted into require calls
In this case, esbuild previously generated two variables with the same name import_react, like this:
```
var import_react = require("react");
var import_react2 = require("@&#8203;remix-run/react");
```
That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.
Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)

Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android ARM without installing the Android build tools.

So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the esbuild-wasm package but it's installed automatically when you install the esbuild package on Android ARM. So packages that depend on the esbuild package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.

This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g. --serve). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.
Attempt to better support Yarn's ignorePatternData feature (#2495)

Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the ignorePatternData property of .pnp.data.json. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.

In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:
- (?!\.)
- (?!(?:^|\/)\.)
- (?!\.{1,2}(?:\/|$))
- (?!(?:^|\/)\.{1,2}(?:\/|$))
These seem to be used by Yarn to avoid the . and .. path segments in the middle of relative paths. The removal of these character sequences seems relatively harmless in this case since esbuild shouldn't ever generate such path segments. This change should add support to esbuild for Yarn's pnpIgnorePatterns feature.
Fix non-determinism issue with legacy block-level function declarations and strict mode (#2537)

When function declaration statements are nested inside a block in strict mode, they are supposed to only be available within that block's scope. But in "sloppy mode" (which is what non-strict mode is commonly called), they are supposed to be available within the whole function's scope:
```
// This returns 1 due to strict mode
function test1() {
  'use strict'
  function fn() { return 1 }
  if (true) { function fn() { return 2 } }
  return fn()
}

// This returns 2 due to sloppy mode
function test2() {
  function fn() { return 1 }
  if (true) { function fn() { return 2 } }
  return fn()
}
```
To implement this, esbuild compiles these two functions differently to reflect their different semantics:
```
function test1() {
  "use strict";
  function fn() {
    return 1;
  }
  if (true) {
    let fn2 = function() {
      return 2;
    };
  }
  return fn();
}
function test2() {
  function fn() {
    return 1;
  }
  if (true) {
    let fn2 = function() {
      return 2;
    };
    var fn = fn2;
  }
  return fn();
}
```
However, the compilation had a subtle bug where the automatically-generated function-level symbols for multible hoisted block-level function declarations in the same block a sloppy-mode context were generated in a random order if the output was in strict mode, which could be the case if TypeScript's alwaysStrict setting was set to true. This lead to non-determinism in the output as the minifier would randomly exchange the generated names for these symbols on different runs. This bug has been fixed by sorting the keys of the unordered map before iterating over them.
Fix parsing of @keyframes with string identifiers (#2555)

Firefox supports @keyframes with string identifier names. Previously this was treated as a syntax error by esbuild as it doesn't work in any other browser. The specification allows for this however, so it's technically not a syntax error (even though it would be unwise to use this feature at the moment). There was also a bug where esbuild would remove the identifier name in this case as the syntax wasn't recognized.

This release changes esbuild's parsing of @keyframes to now consider this case to be an unrecognized CSS rule. That means it will be passed through unmodified (so you can now use esbuild to bundle this Firefox-specific CSS) but the CSS will not be pretty-printed or minified. I don't think it makes sense for esbuild to have special code to handle this Firefox-specific syntax at this time. This decision can be revisited in the future if other browsers add support for this feature.
Add the --jsx-side-effects API option (#2539, #2546)

By default esbuild assumes that JSX expressions are side-effect free, which means they are annoated with /* @__PURE__ */ comments and are removed during bundling when they are unused. This follows the common use of JSX for virtual DOM and applies to the vast majority of JSX libraries. However, some people have written JSX libraries that don't have this property. JSX expressions can have arbitrary side effects and can't be removed. If you are using such a library, you can now pass --jsx-side-effects to tell esbuild that JSX expressions have side effects so it won't remove them when they are unused.

This feature was contributed by @rtsao.

Configuration

📅 Schedule: Branch creation - "every weekend" in timezone America/Vancouver, Automerge - 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, click this checkbox.

This PR has been generated by Mend Renovate. View repository job log here.

Sep 25 '22 16:09 renovate[bot]

⚠️ No Changeset found

Latest commit: 8ba0d37528148449f5134ec63a402ac3bdf35084

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sep 25 '22 16:09 changeset-bot[bot]

webstone-plugins webstone-plugins copied to clipboard

chore(deps): update dependency esbuild to ^0.15.11

Release Notes

v0.15.11

v0.15.10

v0.15.9

v0.15.8

Configuration

⚠️ No Changeset found

webstone-plugins
webstone-plugins copied to clipboard

`v0.15.11`

`v0.15.10`

`v0.15.9`

`v0.15.8`