[Snyk] Upgrade esbuild from 0.12.29 to 0.14.14

Snyk has created this PR to upgrade esbuild from 0.12.29 to 0.14.14.

merge advice :information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 31 versions ahead of your current version.
The recommended version was released 6 days ago, on 2022-01-25.

Release notes

Package name: esbuild

0.14.14 - 2022-01-25
- 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 - 2022-01-22

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(`
          ^

Error:
You installed esbuild on another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.

Specifically the "esbuild-linux-arm64" package is present but this platform
needs the "esbuild-darwin-arm64" package instead. People often get into this
situation by installing esbuild on Windows or macOS and copying "node_modules"
into a Docker image that runs Linux, or by copying "node_modules" between
Windows and WSL environments.

If you are installing with npm, you can try not copying the "node_modules"
directory when you copy the files over, and running "npm ci" or "npm install"
on the destination platform after the copy. Or you could consider using yarn
instead which has built-in support for installing a package on multiple
platforms simultaneously.

If you are installing with yarn, you can try listing both this platform and the
other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
Keep in mind that this means multiple copies of esbuild will be present.

Another alternative is to use the "esbuild-wasm" package instead, which works
the same way on all platforms. But it comes with a heavy performance cost and
can sometimes be 10x slower than the "esbuild" package, so you may also not
want to do that.

    at generateBinPath (./node_modules/esbuild/bin/esbuild:106:17)
    at Object.<anonymous> (./node_modules/esbuild/bin/esbuild:161:39)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

0.14.12 - 2022-01-20
- Ignore invalid @ import rules in CSS (#1946)
  
  In CSS, @ import rules must come first before any other kind of rule (except for @ charset rules). Previously esbuild would warn about incorrectly ordered @ import rules and then hoist them to the top of the file. This broke people who wrote invalid @ import rules in the middle of their files and then relied on them being ignored. With this release, esbuild will now ignore invalid @ import rules and pass them through unmodified. This more accurately follows the CSS specification. Note that this behavior differs from other tools like Parcel, which does hoist CSS @ import rules.
- Print invalid CSS differently (#1947)
  
  This changes how esbuild prints nested @ import statements that are missing a trailing ;, which is invalid CSS. The result is still partially invalid CSS, but now printed in a better-looking way:
```
/* Original code */
.bad { @ import url("other") }
.red { background: red; }

/* Old output (with --minify) */
.bad{@ import url(other) } .red{background: red;}}

/* New output (with --minify) */
.bad{@ import url(other);}.red{background:red}
```
- Warn about CSS nesting syntax (#1945)
  
  There's a proposed CSS syntax for nesting rules using the & selector, but it's not currently implemented in any browser. Previously esbuild silently passed the syntax through untransformed. With this release, esbuild will now warn when you use nesting syntax with a --target= setting that includes a browser.
- Warn about } and > inside JSX elements
  
  The } and > characters are invalid inside JSX elements according to the JSX specification because they commonly result from typos like these that are hard to catch in code reviews:
```
function F() {
  return <div>></div>;
}
function G() {
  return <div>{1}}</div>;
}
```
  The TypeScript compiler already treats this as an error, so esbuild now treats this as an error in TypeScript files too. That looks like this:
```
✘ [ERROR] The character ">" is not valid inside a JSX element

    example.tsx:2:14:
      2 │   return <div>></div>;
        │               ^
        ╵               {'>'}

  Did you mean to escape it as "{'>'}" instead?

✘ [ERROR] The character "}" is not valid inside a JSX element

    example.tsx:5:17:
      5 │   return <div>{1}}</div>;
        │                  ^
        ╵                  {'}'}

  Did you mean to escape it as "{'}'}" instead?
```
  Babel doesn't yet treat this as an error, so esbuild only warns about these characters in JavaScript files for now. Babel 8 treats this as an error but Babel 8 hasn't been released yet. If you see this warning, I recommend fixing the invalid JSX syntax because it will become an error in the future.
- Warn about basic CSS property typos
  
  This release now generates a warning if you use a CSS property that is one character off from a known CSS property:
```
▲ [WARNING] "marign-left" is not a known CSS property

    example.css:2:2:
      2 │   marign-left: 12px;
        │   ~~~~~~~~~~~
        ╵   margin-left

  Did you mean "margin-left" instead?
```
0.14.11 - 2022-01-09
- Fix a bug with enum inlining (#1903)
  
  The new TypeScript enum inlining behavior had a bug where it worked correctly if you used export enum Foo but not if you used enum Foo and then later export { Foo }. This release fixes the bug so enum inlining now works correctly in this case.
- Warn about module.exports.foo = ... in ESM (#1907)
  
  The module variable is treated as a global variable reference instead of as a CommonJS module reference in ESM code, which can cause problems for people that try to use both CommonJS and ESM exports in the same file. There has been a warning about this since version 0.14.9. However, the warning only covered cases like exports.foo = bar and module.exports = bar but not module.exports.foo = bar. This last case is now handled;
```
▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected

    example.ts:2:0:
      2 │ module.exports.b = 1
        ╵ ~~~~~~

  This file is considered to be an ECMAScript module because of the "export" keyword here:

    example.ts:1:0:
      1 │ export let a = 1
        ╵ ~~~~~~
```
- Enable esbuild's CLI with Deno (#1913)
  
  This release allows you to use Deno as an esbuild installer, without also needing to use esbuild's JavaScript API. You can now use esbuild's CLI with Deno:
```
deno run --allow-all "https://deno.land/x/esbuild@v0.14.11/mod.js" --version
```
0.14.10 - 2021-12-31
Read more
0.14.9 - 2021-12-29
Read more
0.14.8 - 2021-12-23
Read more
0.14.7 - 2021-12-21
Read more
0.14.6 - 2021-12-20
Read more
0.14.5 - 2021-12-14
- Fix an issue with the publishing script
  
  This release fixes a missing dependency issue in the publishing script where it was previously possible for the published binary executable to have an incorrect version number.
0.14.4 - 2021-12-14
0.14.3 - 2021-12-12
0.14.2 - 2021-12-04
0.14.1 - 2021-11-30
0.14.0 - 2021-11-26
0.13.15 - 2021-11-20
0.13.14 - 2021-11-16
0.13.13 - 2021-11-09
0.13.12 - 2021-10-31
0.13.11 - 2021-10-30
0.13.10 - 2021-10-28
0.13.9 - 2021-10-23
0.13.8 - 2021-10-17
0.13.7 - 2021-10-15
0.13.6 - 2021-10-14
0.13.5 - 2021-10-13
0.13.4 - 2021-10-05
0.13.3 - 2021-09-28
0.13.2 - 2021-09-23
0.13.1 - 2021-09-23
0.13.0 - 2021-09-22
0.12.29 - 2021-09-22

from esbuild GitHub release notes

Commit messages

Package name: esbuild

34899aa publish 0.14.14 to npm
d3a89e7 fix #1957: include "file" loader paths in hashes
9411fc1 fix #1956: entry points use the "import" condition
1dd0b94 remove error recovery for CSS meta-syntax and ";"
cccc6c6 fix #1959: parser recovery on invalid "@ keyframes"
4e98e5f add shebang to install script (#1711)
98060a2 publish 0.14.13 to npm
639ff15 fix post-resolved external patterns
345f64c fix #619: make `--external:` more consistent
572240c remove an unused type
3449be5 attempt a better x-platform error message (#1819)
4276739 publish 0.14.12 to npm
eaa3ba8 guard typo detector access behind a mutex
2f6d5fa don't try to correct CSS variables to properties
5859f8c only allow CSS nesting syntax inside a style rule
89fa021 warn about basic CSS property typos
41dea66 small adjustment to try.html
78e0808 warn about `}` and `>` inside JSX elements
11ed34e allow trailing "&" nesting selectors without space
69996b4 add initial support for "@ nest" rules (#1945)
9851b5a warn when CSS nesting syntax is used (#1945)
3d96782 fix #1946: ignore invalid `@ import` rules in CSS
c000b61 fix #1947: improve printing of invalid `@ import`
0a16993 better DCE of inlined calls in else blocks (#1936)

Compare

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

retorquere / zotero-folder-import

[Snyk] Upgrade esbuild from 0.12.29 to 0.14.14 #19

Snyk has created this PR to upgrade esbuild from 0.12.29 to 0.14.14.