build(deps): bump esbuild-wasm from 0.8.27 to 0.16.9

[dependabot]

Bumps esbuild-wasm from 0.8.27 to 0.16.9.

Release notes

Sourced from esbuild-wasm's releases.

v0.16.9

• Update to Unicode 15.0.0

  The character tables that determine which characters form valid JavaScript identifiers have been updated from Unicode version 14.0.0 to the newly-released Unicode version 15.0.0. I'm not putting an example in the release notes because all of the new characters will likely just show up as little squares since fonts haven't been updated yet. But you can read https://www.unicode.org/versions/Unicode15.0.0/#Summary for more information about the changes.

• Disallow duplicate lexically-declared names in nested blocks and in strict mode

  In strict mode or in a nested block, it's supposed to be a syntax error to declare two symbols with the same name unless all duplicate entries are either function declarations or all var declarations. However, esbuild was overly permissive and allowed this when duplicate entries were either function declarations or var declarations (even if they were mixed). This check has now been made more restrictive to match the JavaScript specification:

  // JavaScript allows this
  var a
  function a() {}
  {
    var b
    var b
    function c() {}
    function c() {}
  }
  // JavaScript doesn't allow this
  {
  var d
  function d() {}
  }

• Add a type declaration for the new empty loader (#2755)

  I forgot to add this in the previous release. It has now been added.

  This fix was contributed by @​fz6m.

• Add support for the v flag in regular expression literals

  People are currently working on adding a v flag to JavaScript regular expresions. You can read more about this flag here: https://v8.dev/features/regexp-v-flag. This release adds support for parsing this flag, so esbuild will now no longer consider regular expression literals with this flag to be a syntax error. If the target is set to something other than esnext, esbuild will transform regular expression literals containing this flag into a new RegExp() constructor call so the resulting code doesn't have a syntax error. This enables you to provide a polyfill for RegExp that implements the v flag to get your code to work at run-time. While esbuild doesn't typically adopt proposals until they're already shipping in a real JavaScript run-time, I'm adding it now because a) esbuild's implementation doesn't need to change as the proposal evolves, b) this isn't really new syntax since regular expression literals already have flags, and c) esbuild's implementation is a trivial pass-through anyway.

• Avoid keeping the name of classes with static name properties

  The --keep-names property attempts to preserve the original value of the name property for functions and classes even when identifiers are renamed by the minifier or to avoid a name collision. This is currently done by generating code to assign a string to the name property on the function or class object. However, this should not be done for classes with a static name property since in that case the explicitly-defined name property overwrites the automatically-generated class name. With this release, esbuild will now no longer attempt to preserve the name property for classes with a static name property.

v0.16.8

• Allow plugins to resolve injected files (#2754)

  Previously paths passed to the inject feature were always interpreted as file system paths. This meant that onResolve plugins would not be run for them and esbuild's default path resolver would always be used. This meant that the inject feature couldn't be used in the browser since the browser doesn't have access to a file system. This release runs paths passed to inject through esbuild's full path resolution pipeline so plugins now have a chance to handle them using onResolve callbacks. This makes it possible to write a plugin that makes esbuild's inject work in the browser.

• Add the empty loader (#1541, #2753)

  The new empty loader tells esbuild to pretend that a file is empty. So for example --loader:.css=empty effectively skips all imports of .css files in JavaScript so that they aren't included in the bundle, since import "./some-empty-file" in JavaScript doesn't bundle anything. You can also use the empty loader to remove asset references in CSS files. For example --loader:.png=empty causes esbuild to replace asset references such as url(image.png) with url() so that they are no longer included in the resulting style sheet.

... (truncated)

Changelog

Sourced from esbuild-wasm's changelog.

Changelog: 2020

This changelog documents all esbuild versions published in the year 2020 (versions 0.3.0 through 0.8.28).

0.8.28

• Add a --summary flag that prints helpful information after a build (#631)

  Normally esbuild's CLI doesn't print anything after doing a build if nothing went wrong. This allows esbuild to be used as part of a more complex chain of tools without the output cluttering the terminal. However, sometimes it is nice to have a quick overview in your terminal of what the build just did. You can now add the --summary flag when using the CLI and esbuild will print a summary of what the build generated. It looks something like this:

  $ ./esbuild --summary --bundle src/Three.js --outfile=build/three.js --sourcemap
  build/three.js      1.0mb ⚠️
  build/three.js.map  1.8mb
  ⚡ Done in 43ms
  

• Keep unused imports in TypeScript code in one specific case (#604)

  The official TypeScript compiler always removes imported symbols that aren't used as values when converting TypeScript to JavaScript. This is because these symbols could be types and not removing them could result in a run-time module instantiation failure because of missing exports. This even happens when the tsconfig.json setting "importsNotUsedAsValues" is set to "preserve". Doing this just keeps the import statement itself but confusingly still removes the imports that aren't used as values.

  Previously esbuild always exactly matched the behavior of the official TypeScript compiler regarding import removal. However, that is problematic when trying to use esbuild to compile a partial module such as when converting TypeScript to JavaScript inside a file written in the Svelte programming language. Here is an example:

  <script lang="ts">
    import Counter from './Counter.svelte';
    export let name: string = 'world';
  </script>
  <main>
    <h1>Hello {name}!</h1>
    <Counter />
  </main>

  The current Svelte compiler plugin for TypeScript only provides esbuild with the contents of the <script> tag so to esbuild, the import Counter appears to be unused and is removed.

  In this release, esbuild deliberately deviates from the behavior of the official TypeScript compiler if all of these conditions are met:

  • The "importsNotUsedAsValues" field in tsconfig.json must be present and must not be set to "remove". This is necessary because this is the only case where esbuild can assume that all imports are values instead of types. Any imports that are types will cause a type error when the code is run through the TypeScript type checker. To import types when the importsNotUsedAsValues setting is active, you must use the TypeScript-specific import type syntax instead.

  • You must not be using esbuild as a bundler. When bundling, esbuild needs to assume that it's not seeing a partial file because the bundling process requires renaming symbols to avoid cross-file name collisions.

  • You must not have identifier minification enabled. It's useless to preserve unused imports in this case because referencing them by name won't work anyway. And keeping the unused imports would be counter-productive to minification since they would be extra unnecessary data in the output file.

  This should hopefully allow esbuild to be used as a TypeScript-to-JavaScript converter for programming languages such as Svelte, at least in many cases. The build pipeline in esbuild wasn't designed for compiling partial modules and this still won't be a fully robust solution (e.g. some variables may be renamed to avoid name collisions in rare cases). But it's possible that these cases are very unlikely to come up in practice. Basically this change to keep unused imports in this case should be useful at best and harmless at worst.

Commits

• 29ae56a publish 0.16.9 to npm
• d2aa4eb fix lexically-declared names in strict mode
• 0c15c1e implement test262 json module loading
• 55e2738 fix js tests for node v19+
• 88ef1de update source-map library for node v19
• 7c249a9 avoid keep names of class static name properties
• ff1681e more test262 adjustments
• 5ee1dbf attempt to run test262 tests in a harness
• 94fcbf6 rewrite the test262 script
• b5ec405 support the v regular expression literal flag
• Additional commits viewable 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)

[dependabot]

Superseded by #85.