Update dependency esbuild-wasm to v0.8.2

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
esbuild-wasm	devDependencies	minor	0.6.28 -> 0.8.2

---

Release Notes

evanw/esbuild

v0.8.2

比较 Source

• Fix the omission of outbase in the JavaScript API (#​471)

  The original PR for the outbase setting added it to the CLI and Go APIs but not the JavaScript API. This release adds it to the JavaScript API too.

• Fix the TypeScript type definitions (#​499)

  The newly-released plugins option in the TypeScript type definitions was incorrectly marked as non-optional. It is now optional. This fix was contributed by @​remorses.

v0.8.1

比较 Source

• The initial version of the plugin API (#​111)

  The plugin API lets you inject custom code inside esbuild's build process. You can write plugins in either JavaScript or Go. Right now you can add an "on resolve" callback to determine where import paths go and an "on load" callback to determine what the imported file contains. These two primitives are very powerful, especially in combination with each other.

  Here's a simple example plugin to show off the API in action. Let's say you wanted to enable a workflow where you can import environment variables like this:

  // app.js
  import { NODE_ENV } from 'env'
  console.log(`NODE_ENV is ${NODE_ENV}`)

  This is how you might do that from JavaScript:

  let envPlugin = {
    name: 'env-plugin',
    setup(build) {
      build.onResolve({ filter: /^env$/ }, args => ({
        path: args.path,
        namespace: 'env',
      }))
  
      build.onLoad({ filter: /.*/, namespace: 'env' }, () => ({
        contents: JSON.stringify(process.env),
        loader: 'json',
      }))
    },
  }
  
  require('esbuild').build({
    entryPoints: ['app.js'],
    bundle: true,
    outfile: 'out.js',
    plugins: [envPlugin],
    logLevel: 'info',
  }).catch(() => process.exit(1))

  This is how you might do that from Go:

  package main
  
  import (
    "encoding/json"
    "os"
    "strings"
  
    "github.com/evanw/esbuild/pkg/api"
  )
  
  var envPlugin = api.Plugin{
    Name: "env-plugin",
    Setup: func(build api.PluginBuild) {
      build.OnResolve(api.OnResolveOptions{Filter: `^envThis PR contains the following updates:

Package	Type	Update	Change
esbuild-wasm	devDependencies	minor	0.6.28 -> 0.8.2

---

},
func(args api.OnResolveArgs) (api.OnResolveResult, error) {
return api.OnResolveResult{
Path: args.Path,
Namespace: "env",
}, nil
})

    build.OnLoad(api.OnLoadOptions{Filter: `.*`, Namespace: "env"},
      func(args api.OnLoadArgs) (api.OnLoadResult, error) {
        mappings := make(map[string]string)
        for _, item := range os.Environ() {
          if equals := strings.IndexByte(item, '='); equals != -1 {
            mappings[item[:equals]] = item[equals+1:]
          }
        }
        bytes, _ := json.Marshal(mappings)
        contents := string(bytes)
        return api.OnLoadResult{
          Contents: &contents,
          Loader: api.LoaderJSON,
        }, nil
      })
  },
}

func main() {
  result := api.Build(api.BuildOptions{
    EntryPoints: []string{"app.js"},
    Bundle:      true,
    Outfile:     "out.js",
    Plugins:     []api.Plugin{envPlugin},
    Write:       true,
    LogLevel:    api.LogLevelInfo,
  })

  if len(result.Errors) > 0 {
    os.Exit(1)
  }
}
```

  Comprehensive documentation for the plugin API is not yet available but is coming soon.

• Add the outbase option (#​471)

  Currently, esbuild uses the lowest common ancestor of the entrypoints to determine where to place each entrypoint's output file. This is an excellent default, but is not ideal in some situations. Take for example an app with a folder structure similar to Next.js, with js files at pages/a/b/c.js and pages/a/b/d.js. These two files correspond to the paths /a/b/c and /a/b/d. Ideally, esbuild would emit out/a/b/c.js and out/a/b/d.js. However, esbuild identifies pages/a/b as the lowest common ancestor and emits out/c.js and out/d.js. This release introduces an --outbase argument to the cli that allows the user to choose which path to base entrypoint output paths on. With this change, running esbuild with --outbase=pages results in the desired behavior. This change was contributed by @​nitsky.

v0.8.0

比较 Source

This release contains backwards-incompatible changes. Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as recommended by npm). You should either be pinning the exact version of esbuild in your package.json file or be using a version range syntax that only accepts patch upgrades such as ^0.7.0. See the documentation about semver for more information.

The breaking changes are as follows:

• Changed the transform API result object

  For the transform API, the return values js and jsSourceMap have been renamed to code and map respectively. This is because esbuild now supports CSS as a first-class content type, and returning CSS code in a variable called js made no sense.

• The class field transform is now more accurate

  Class fields look like this:

  class Foo {
    foo = 123
  }

  Previously the transform for class fields used a normal assignment for initialization:

  class Foo {
    constructor() {
      this.foo = 123;
    }
  }

  However, this doesn't exactly follow the initialization behavior in the JavaScript specification. For example, it can cause a setter to be called if one exists with that property name, which isn't supposed to happen. A more accurate transform that used Object.defineProperty() instead was available under the --strict:class-fields option.

  This release removes the --strict:class-fields option and makes that the default behavior. There is no longer a way to compile class fields to normal assignments instead, since that doesn't follow JavaScript semantics. Note that for legacy reasons, TypeScript code will still compile class fields to normal assignments unless useDefineForClassFields is enabled in tsconfig.json just like the official TypeScript compiler.

• When bundling stdin using the API, resolveDir is now required to resolve imports

  The resolveDir option specifies the directory to resolve relative imports against. Previously it defaulted to the current working directory. Now it no longer does, so you must explicitly specify it if you need it:

  const result = await esbuild.build({
    stdin: {
      contents,
      resolveDir,
    },
    bundle: true,
    outdir,
  })

  This was changed because the original behavior was unintentional, and because being explicit seems better in this case. Note that this only affects the JavaScript and Go APIs. The resolution directory for stdin passed using the command-line API still defaults to the current working directory.

  In addition, it is now possible for esbuild to discover input source maps linked via //# sourceMappingURL= comments relative to the resolveDir for stdin. This previously only worked for files with a real path on the file system.

• Made names in the Go API consistent

  Previously some of the names in the Go API were unnecessarily different than the corresponding names in the CLI and JavaScript APIs. This made it harder to write documentation and examples for these APIs that work consistently across all three API surfaces. These different names in the Go API have been fixed:

  • Defines → Define
  • Externals → External
  • Loaders → Loader
  • PureFunctions → Pure

• The global name parameter now takes a JavaScript expression (#​293)

  The global name parameter determines the name of the global variable created for exports with the IIFE output format. For example, a global name of abc would generate the following IIFE:

  var abc = (() => {
    ...
  })();

  Previously this name was injected into the source code verbatim without any validation. This meant a global name of abc.def would generate this code, which is a syntax error:

  var abc.def = (() => {
    ...
  })();

  With this release, a global name of abc.def will now generate the following code instead:

  var abc = abc || {};
  abc.def = (() => {
    ...
  })();

  The full syntax is an identifier followed by one or more property accesses. If you need to include a . character in your property name, you can use an index expression instead. For example, the global name versions['1.0'] will generate the following code:

  var versions = versions || {};
  versions["1.0"] = (() => {
    ...
  })();

• Removed the workaround for document.all with nullish coalescing and optional chaining

  The --strict:nullish-coalescing and --strict:optional-chaining options have been removed. They only existed to address a theoretical problem where modern code that uses the new ?? and ?. operators interacted with the legacy document.all object that has been deprecated for a long time. Realistically this case is extremely unlikely to come up in practice, so these obscure options were removed to simplify the API and reduce code complexity. For what it's worth this behavior also matches Terser, a commonly-used JavaScript minifier.

v0.7.22

比较 Source

• Add tsconfigRaw to the transform API (#​483)

  The build API uses access to the file system and doesn't run in the browser, but the transform API doesn't access the file system and can run in the browser. Previously you could only use the build API for certain scenarios involving TypeScript code and tsconfig.json files, such as configuring the importsNotUsedAsValues setting.

  You can now use tsconfig.json with the transform API by passing in the raw contents of that file:

  let result = esbuild.transformSync(ts, {
    loader: 'ts',
    tsconfigRaw: {
      compilerOptions: {
        importsNotUsedAsValues: 'preserve',
      },
    },
  })

  Right now four values are supported with the transform API: jsxFactory, jsxFragmentFactory, useDefineForClassFields, and importsNotUsedAsValues. The values extends, baseUrl, and paths are not supported because they require access to the file system and the transform API deliberately does not access the file system.

  You can also pass the tsconfig.json file as a string instead of a JSON object if you prefer. This can be useful because tsconfig.json files actually use a weird pseudo-JSON syntax that allows comments and trailing commas, which means it can't be parsed with JSON.parse().

• Warn about process.env.NODE_ENV

  Some popular browser-oriented libraries such as React use process.env.NODE_ENV even though this is not an API provided by the browser. While esbuild makes it easy to replace this at compile time using the --define feature, you must still do this manually and it's easy to forget. Now esbuild will warn you if you're bundling code containing process.env.NODE_ENV for the browser and you haven't configured it to be replaced by something.

• Work around a bug in Safari for the run-time code (#​489)

  The Object.getOwnPropertyDescriptor function in Safari is broken for numeric properties. It incorrectly returns undefined, which crashes the run-time code esbuild uses to bind modules together. This release contains code to avoid a crash in this case.

v0.7.21

比较 Source

• Use bracketed escape codes for non-BMP characters

  The previous release introduced code that escapes non-ASCII characters using ASCII escape sequences. Since JavaScript uses UCS-2/UTF-16 internally, a non-BMP character such as 𐀀 ended up being encoded using a surrogate pair: \uD800\uDC00. This is fine when the character is contained in a string, but it causes a syntax error when that character is used as an identifier.

  This release fixes this issue by using the newer bracketed escape code instead: \u{10000}. One complication with doing this is that this escape code won't work in older environments without ES6 support. Because of this, using identifiers containing non-BMP characters is now an error if the configured target environment doesn't support bracketed escape codes.

• Escape non-ASCII characters in properties

  The previous release overlooked the need to escape non-ASCII characters in properties in various places in the grammar (e.g. object literals, property accesses, import and export aliases). This resulted in output containing non-ASCII characters even with --charset=ascii. These characters should now always be escaped, even in properties.

v0.7.20

比较 Source

• Default to ASCII-only output (#​70, #​485)

  While esbuild's output is encoded using UTF-8 encoding, there are many other character encodings in the wild (e.g. Windows-1250). You can explicitly mark the output files as UTF-8 by adding <meta charset="utf-8"> to your HTML page or by including charset=utf-8 in the Content-Type header sent by your server. This is probably a good idea regardless of the contents of esbuild's output since information being displayed to users is probably also encoded using UTF-8.

  However, sometimes it's not possible to guarantee that your users will be running your code as UTF-8. For example, you may not control the server response or the contents of the HTML page that loads your script. Also, if your code needs to run in IE, there are certain cases where IE may ignore the <meta charset="utf-8"> tag and make up another encoding instead.

  Also content encoded using UTF-8 may be parsed up to 1.7x slower by the browser than ASCII-only content, at least according to this blog post from the V8 team: https://v8.dev/blog/scanner. The official recommendation is to "avoid non-ASCII identifiers where possible" to improve parsing performance.

  For these reasons, esbuild's default output has been changed to ASCII-only. All Unicode code points in identifiers and strings that are outside of the printable ASCII range (\x20-\x7E inclusive) are escaped using backslash escape sequences. If you would like to use raw UTF-8 encoding instead, you can pass the --charset=utf8 flag to esbuild.

  Further details:

  • This does not yet escape non-ASCII characters embedded in regular expressions. This is because esbuild does not currently parse the contents of regular expressions at all. The flag was added despite this limitation because it's still useful for code that doesn't contain cases like this.

  • This flag does not apply to comments. I believe preserving non-ASCII data in comments should be fine because even if the encoding is wrong, the run time environment should completely ignore the contents of all comments. For example, the V8 blog post mentions an optimization that avoids decoding comment contents completely. And all comments other than license-related comments are stripped out by esbuild anyway.

  • This new --charset flag simultaneously applies to all output file types (JavaScript, CSS, and JSON). So if you configure your server to send the correct Content-Type header and want to use --charset=utf8, make sure your server is configured to treat both .js and .css files as UTF-8.

• Interpret escape sequences in CSS tokens

  Escape sequences in CSS tokens are now interpreted. This was already the case for string and URL tokens before, but this is now the case for all identifier-like tokens as well. For example, c\6flor: #\66 00 is now correctly recognized as color: #f00.

• Support .css with the --out-extension option

  The --out-extension option was added so you could generate .mjs and .cjs files for node like this: --out-extension:.js=.mjs. However, now that CSS is a first-class content type in esbuild, this should also be available for .css files. I'm not sure why you would want to do this, but you can now do --out-extension:.css=.something too.

v0.7.19

比较 Source

• Add the --avoid-tdz option for large bundles in Safari (#​478)

  This is a workaround for a performance issue with certain large JavaScript files in Safari.

  First, some background. In JavaScript the var statement is "hoisted" meaning the variable is declared immediately in the closest surrounding function, module, or global scope. Accessing one of these variables before its declaration has been evaluated results in the value undefined. In ES6 the const, let, and class statements introduce what's called a "temporal dead zone" or TDZ. This means that, unlike var statements, accessing one of these variable before its declaration has been evaluated results in a ReferenceError being thrown. It's called a "temporal dead zone" because it's a zone of time in which the variable is inaccessible.

  According to this WebKit bug, there's a severe performance issue with the tracking of TDZ checks in JavaScriptCore, the JavaScript JIT compiler used by WebKit. In a large private code base I have access to, the initialization phase of the bundle produced by esbuild runs 10x faster in Safari if top-level const, let, and class are replaced with var. It's a difference between a loading time of about 2sec vs. about 200ms. This transformation is not enabled by default because it changes the semantics of the code (it removes the TDZ and const assignment checks). However, this change in semantics may be acceptable for you given the performance trade-off. You can enable it with the --avoid-tdz flag.

• Warn about assignment to const symbols

  Now that some const symbols may be converted to var due to --avoid-tdz, it seems like a good idea to at least warn when an assignment to a const symbol is detected during bundling. Otherwise accidental assignments to const symbols could go unnoticed if there isn't other tooling in place such as TypeScript or a linter.

v0.7.18

比较 Source

• Treat paths in CSS without a ./ or ../ prefix as relative (#​469)

  JavaScript paths starting with ./ or ../ are considered relative paths, while other JavaScript paths are considered package paths and are looked up in that package's node_modules directory. Currently url() paths in CSS files use that same logic, so url(images/image.png) checks for a file named image.png in the image package.

  This release changes this behavior. Now url(images/image.png) first checks for ./images/image.png, then checks for a file named image.png in the image package. This behavior should match the behavior of Webpack's standard css-loader package.

• Import non-enumerable properties from CommonJS modules (#​472)

  You can now import non-enumerable properties from CommonJS modules using an ES6 import statement. Here's an example of a situation where that might matter:

  // example.js
  module.exports = class {
    static method() {}
  }

  import { method } from './example.js'
  method()

  Previously that didn't work because the method property is non-enumerable. This should now work correctly.

  A minor consequence of this change is that re-exporting from a file using export * from will no longer re-export properties inherited from the prototype of the object assigned to module.exports. This is because run-time property copying has been changed from a for-in loop to Object.getOwnPropertyNames. This change should be inconsequential because as far as I can tell this isn't something any other bundler supports either.

• Remove arrow functions in runtime with --target=es5

  The --target=es5 flag is intended to prevent esbuild from introducing any ES6+ syntax into the generated output file. For example, esbuild usually shortens {x: x} into {x} since it's shorter, except that requires ES6 support. This release fixes a bug where => arrow expressions in esbuild's runtime of helper functions were not converted to function expressions when --target=es5 was present.

• Merge local variable declarations across files when minifying

  Currently files are minified in parallel and then concatenated together for maximum performance. However, that means certain constructs are not optimally minified if they span multiple files. For example, a bundle containing two files var a = 1 and var b = 2 should ideally become var a=1,b=2; after minification but it currently becomes var a=0;var b=2; instead due to parallelism.

  With this release, esbuild will generate var a=1,b=2; in this scenario. This is achieved by splicing the two files together to remove the trailing ; and the leading var, which is more complicated than it sounds when you consider rewriting the source maps.

v0.7.17

比较 Source

• Add --public-path= for the file loader (#​459)

  The file loader causes importing a file to cause that file to be copied into the output directory. The name of the file is exported as the default export:

  // Assume ".png" is set to the "file" loader
  import name from 'images/image.png'
  
  // This prints something like "image.L3XDQOAT.png"
  console.log(name)

  The new public path setting configures the path prefix. So for example setting it to https://www.example.com/v1 would change the output text for this example to https://www.example.com/v1/image.L3XDQOAT.png.

• Add --inject: for polyfills (#​451)

  It's now possible to replace global variables with imports from a file with --inject:file.js. Note that file.js must export symbols using the export keyword for this to work. This can be used to polyfill a global variable in code you don't control. For example:

  // process.js
  export let process = {cwd() {}}

  // entry.js
  console.log(process.cwd())

  Building this with esbuild entry.js --inject:process.js gives this:

  let process = {cwd() {
  }};
  console.log(process.cwd());

  You can also combine this with the existing --define feature to be more selective about what you import. For example:

  // process.js
  export function dummy_process_cwd() {}

  // entry.js
  console.log(process.cwd())

  Building this with esbuild entry.js --inject:process.js --define:process.cwd=dummy_process_cwd gives this:

  function dummy_process_cwd() {
  }
  console.log(dummy_process_cwd());

  Note that this means you can use --inject to provide the implementation for JSX expressions (e.g. auto-import the react package):

  // shim.js
  export * as React from 'react'

  // entry.jsx
  console.log(<div/>)

  Building this with esbuild entry.js --inject:shim.js --format=esm gives this:

  import * as React from "react";
  console.log(/* @​__PURE__ */ React.createElement("div", null));

  You can also use --inject:file.js with files that have no exports. In that case the injected file just comes first before the rest of the output as if every input file contained import "./file.js". Because of the way ECMAScript modules work, this injection is still "hygienic" in that symbols with the same name in different files are renamed so they don't collide with each other.

  If you want to conditionally import a file only if the export is actually used, you should mark the injected file as not having side effects by putting it in a package and adding "sideEffects": false in that package's package.json file. This setting is a convention from Webpack that esbuild respects for any imported file, not just files used with --inject.

• Add an ECMAScript module build for the browser (#​342)

  The current browser API lets you use esbuild in the browser via the esbuild-wasm package and a script tag:

  <script src="node_modules/esbuild-wasm/lib/browser.js"></script>
  <script>
    esbuild.startService({
      wasmURL: 'node_modules/esbuild-wasm/esbuild.wasm',
    }).then(service => {
      // Use service
    })
  </script>

  In addition to this approach, you can now also use esbuild in the browser from a module-type script (note the use of esm/browser.js instead of lib/browser.js):

  <script type="module">
    import * as esbuild from 'node_modules/esbuild-wasm/esm/browser.js'
    esbuild.startService({
      wasmURL: 'node_modules/esbuild-wasm/esbuild.wasm',
    }).then(service => {
      // Use service
    })
  </script>

  Part of this fix was contributed by @​calebeby.

v0.7.16

比较 Source

• Fix backward slashes in source maps on Windows (#​463)

  The relative path fix in the previous release caused a regression where paths in source maps contained \ instead of / on Windows. That is incorrect because source map paths are URLs, not file system paths. This release replaces \ with / for consistency on Windows.

• module.require() is now an alias for require() (#​455)

  Some packages such as apollo-server use module.require() instead of require() with the intent of bypassing the bundler's require and calling the underlying function from node instead. Unfortunately that doesn't actually work because CommonJS module semantics means module is a variable local to that file's CommonJS closure instead of the host's module object.

  This wasn't an issue when using apollo-server with Webpack because the literal expression module.require() is automatically rewritten to require() by Webpack: webpack/webpack#​7750. To get this package to work, esbuild now matches Webpack's behavior here. Calls to module.require() will become external calls to require() as long as the required path has been marked as external.

v0.7.15

比较 Source

• Lower export * as syntax for ES2019 and below

  The export * from 'path' syntax was added in ES2015 but the export * as name from 'path' syntax was added more recently in ES2020. This is a shorthand for an import followed by an export:

  // ES2020
  export * as name from 'path'
  
  // ES2019
  import * as name from 'path'
  export {name}

  With this release, esbuild will now undo this shorthand syntax when using --target=es2019 or below.

• Better code generation for TypeScript files with type-only exports (#​447)

  Previously TypeScript files could have an unnecessary CommonJS wrapper in certain situations. The specific situation is bundling a file that re-exports something from another file without any exports. This happens because esbuild automatically considers a module to be a CommonJS module if there is no ES6 import/export syntax.

  This behavior is undesirable because the CommonJS wrapper is usually unnecessary. It's especially undesirable for cases where the re-export uses export * from because then the re-exporting module is also converted to a CommonJS wrapper (since re-exporting everything from a CommonJS module must be done at run-time). That can also impact the bundle's exports itself if the entry point does this and the format is esm.

  It is generally equivalent to avoid the CommonJS wrapper and just rewrite the imports to an undefined literal instead:

  import {name} from './empty-file'
  console.log(name)

  This can be rewritten to this instead (with a warning generated about name being missing):

  console.log(void 0)

  With this release, this is now how cases like these are handled. The only case where this can't be done is when the import uses the import * as syntax. In that case a CommonJS wrapper is still necessary because the namespace cannot be rewritten to undefined.

• Add support for importsNotUsedAsValues in TypeScript (#​448)

  The importsNotUsedAsValues field in tsconfig.json is now respected. Setting it to "preserve" means esbuild will no longer remove unused imports in TypeScript files. This field was added in TypeScript 3.8.

• Fix relative paths in generated source maps (#​444)

  Currently paths in generated source map files don't necessarily correspond to real file system paths. They are really only meant to be human-readable when debugging in the browser.

  However, the Visual Studio Code debugger expects these paths to point back to the original files on the file system. With this release, it should now always be possible to get back to the original source file by joining the directory containing the source map file with the relative path in the source map.

  This fix was contributed by @​yoyo930021.

v0.7.14

比较 Source

• Fix a bug with compound import statements (#​446)

  Import statements can simultaneously contain both a default import and a namespace import like this:

  import defVal, * as nsVal from 'path'

  These statements were previously miscompiled when bundling if the import path was marked as external, or when converting to a specific output format, and the namespace variable itself was used for something other than a property access. The generated code contained a syntax error because it generated a {...} import clause containing the default import.

  This particular problem was caused by code that converts namespace imports into import clauses for more efficient bundling. This transformation should not be done if the namespace import cannot be completely removed:

  // Can convert namespace to clause
  import defVal, * as nsVal from 'path'
  console.log(defVal, nsVal.prop)

  // Cannot convert namespace to clause
  import defVal, * as nsVal from 'path'
  console.log(defVal, nsVal)

v0.7.13

比较 Source

• Fix mainFields in the JavaScript API (#​440 and #​441)

  It turns out the JavaScript bindings for the mainFields API option didn't work due to a copy/paste error. The fix for this was contributed by @​yoyo930021.

• The benchmarks have been updated

  The benchmarks now include Parcel 2 and Webpack 5 (in addition to Parcel 1 and Webpack 4, which were already included). It looks like Parcel 2 is slightly faster than Parcel 1 and Webpack 5 is significantly slower than Webpack 4.

v0.7.12

比较 Source

• Fix another subtle ordering issue with import statements

  When importing a file while bundling, the import statement was ordered before the imported code. This could affect import execution order in complex scenarios involving nested hybrid ES6/CommonJS modules. The fix was to move the import statement to after the imported code instead. This issue affected the @sentry/browser package.

v0.7.11

比较 Source

• Fix regression in 0.7.9 when minifying with code splitting (#​437)

  In certain specific cases, bundling and minifying with code splitting active can cause a crash. This is a regression that was introduced in version 0.7.9 due to the fix for issue #​421. The crash has been fixed and this case now has test coverage.

v0.7.10

比较 Source

• Recover from bad main field in package.json (#​423)

  Some packages are published with invalid information in the main field of package.json. In that case, path resolution should fall back to searching for a file named index.js before giving up. This matters for the simple-exiftool package, for example.

• Ignore TypeScript types on catch clause bindings (435)

  This fixes an issue where using a type annotation in a catch clause like this was a syntax error:

  try {
  } catch (x: unknown) {
  }

v0.7.9

比较 Source

• Fixed panic when using a url() import in CSS with the --metafile option

  This release fixes a crash that happens when metafile output is enabled and the url() syntax is used in a CSS file to import a successfully-resolved file.

• Minify some CSS colors

  The minifier can now reduce the size of some CSS colors. This is the initial work to start CSS minification in general beyond whitespace removal. There is currently support for minifying hex, rgb()/rgba(), and hsl()/hsla() into hex or shorthand hex. The minification process respects the configured target browser and doesn't use any syntax that wouldn't be supported.

• Lower newer CSS syntax for older browsers

  新建er color syntax such as rgba(255 0 0 / 50%) will be converted to older syntax (in this case rgba(255, 0, 0, 0.5)) when the target browser doesn't support the newer syntax. For example, this happens when using --target=chrome60.

• Fix an ordering issue with import statements (#​421)

  Previously import statements that resolved to a CommonJS module turned into a call to require() inline. This was subtly incorrect when combined with tree shaking because it could sometimes cause imported modules to be reordered:

  import {foo} from './cjs-file'
  import {bar} from './esm-file'
  console.log(foo, bar)

  That code was previously compiled into something like this, which is incorrect because the evaluation of bar may depend on side effects from importing cjs-file.js:

  // ./cjs-file.js
  var require_cjs_file = __commonJS(() => {
    ...
  })
  
  // ./esm-file.js
  let bar = ...;
  
  // ./example.js
  const cjs_file = __toModule(require_cjs_file())
  console.log(cjs_file.foo, bar)

  That code is now compiled into something like this:

  // ./cjs-file.js
  var require_cjs_file = __commonJS(() => {
    ...
  })
  
  // ./example.js
  const cjs_file = __toModule(require_cjs_file())
  
  // ./esm-file.js
  let bar = ...;
  
  // ./example.js
  console.log(cjs_file.foo, bar)

  This now means that a single input file can end up in multiple discontiguous regions in the output file as is the case with example.js here, which wasn't the case before this bug fix.

v0.7.8

比较 Source

• Move external @import rules to the top

  Bundling could cause @import rules for paths that have been marked as external to be inserted in the middle of the CSS file. This would cause them to become invalid and be ignored by the browser since all @import rules must come first at the top of the file. These @import rules are now always moved to the top of the file so they stay valid.

• Better support for @keyframes rules

  The parser now directly understands @keyframes rules, which means it can now format them more accurately and report more specific syntax errors.

• Minify whitespace around commas in CSS

  Whitespace around commas in CSS will now be pretty-printed when not minifying and removed when minifying. So a , b becomes a, b when pretty-printed and a,b when minified.

• Warn about unknown at-rules in CSS

  Using an @rule in a CSS file that isn't known by esbuild now generates a warning and these rules will be passed through unmodified. If they aren't known to esbuild, they are probably part of a CSS preprocessor syntax that should have been compiled away before giving the file to esbuild to parse.

• Recoverable CSS syntax errors are now warnings

  The base CSS syntax can preserve nonsensical rules as long as they contain valid tokens and have matching opening and closing brackets. These rule with incorrect syntax now generate a warning instead of an error and esbuild preserves the syntax in the output file. This makes it possible to use esbuild to process CSS that was generated by another tool that contains bugs.

  For example, the following code is invalid CSS, and was presumably generated by a bug in an automatic prefix generator:

  div {
    -webkit-undefined;
    -moz-undefined;
    -undefined;
  }

  This code will no longer prevent esbuild from processing the CSS file.

• Treat url(...) in CSS files as an import (#​415)

  When bundling, the url(...) syntax in CSS now tries to resolve the URL as a path using the bundler's built in path resolution logic. The following loaders can be used with this syntax: text, base64, file, dataurl, and binary.

• Automatically treat certain paths as external

  The following path forms are now automatically considered external:

  • http://example.com/image.png

  • https://example.com/image.png

  • //example.com/image.png

  • data:image/png;base64,iVBORw0KGgo=

    In addition, paths starting with # are considered external in CSS files, which allows the following syntax to continue to work:

    path {
      /* This can be useful with SVG DOM content */
      fill: url(#filter);
    }

v0.7.7

比较 Source

• Fix TypeScript decorators on static members

  This release fixes a bug with the TypeScript transform for the experimentalDecorators setting. Previously the target object for all decorators was the class prototype, which was incorrect for static members. Static members now correctly use the class object itself as a target object.

• Experimental support for CSS syntax (#​20)

  This release introduces the new css loader, enabled by default for .css files. It has the following features:

  • You can now use esbuild to process CSS files by passing a CSS file as an entry point. This means CSS is a new first-class file type and you can use it without involving any JavaScript code at all.

  • When bundling is enabled, esbuild will bundle multiple CSS files together if they are referenced using the @import "./file.css"; syntax. CSS files can be excluded from the bundle by marking them as external similar to JavaScript files.

  • There is basic support for pretty-printing CSS, and for whitespace removal when the --minify flag is present. There isn't any support for CSS syntax compression yet. Note that pretty-printing and whitespace removal both rely on the CSS syntax being recognized. Currently esbuild only recognizes certain CSS syntax and passes through unrecognized syntax unchanged.

    Some things to keep in mind:

  • CSS support is a significant undertaking and this is the very first release. There are almost certainly going to be issues. This is an experimental release to land the code and get feedback.

  • There is no support for CSS modules yet. Right now all class names are in the global namespace. Importing a CSS file into a JavaScript file will not result in any import names.

  • There is currently no support for code splitting of CSS. I haven't tested multiple entry-point scenarios yet and code splitting will require additional changes to the AST format.

v0.7.6

比较 Source

• Fix JSON files with multiple entry points (#​413)

  This release fixes an issue where a single build operation containing multiple entry points and a shared JSON file which is used by more than one of those entry points can generate incorrect code for the JSON file when code splitting is disabled. The problem was not cloning the AST representing the JSON file before mutating it.

• Silence warnings about require.resolve() for external paths (#​410)

  Bundling code containing a call to node's require.resolve() function causes a warning because it's an unsupported use of require that does not end up being bundled. For example, the following code will likely have unexpected behavior if foo ends up being bundled because the require() call is evaluated at bundle time but the require.resolve() call is evaluated at run time:

  let foo = {
    path: require.resolve('foo'),
    module: require('foo'),
  };

  These warnings can already be disabled by surrounding the code with a try/catch statement. With this release, these warnings can now also be disabled by marking the path as external.

• Ensure external relative paths start with ./ or ../

  Individual file paths can be marked as external in addition to package paths. In that case, the path to the file is rewritten to be relative to the output directory. However, previously the relative path for files in the output directory itself did not start with ./, meaning they could potentially be interpreted as a package path instead of a relative path. These paths are now prefixed with ./ to avoid this edge case.

v0.7.5

比较 Source

• Fix an issue with automatic semicolon insertion after let (#​409)

  The character sequence let can be considered either a keyword or an identifier depending on the context. A fix was previously landed in version 0.6.31 to consider let as an identifier in code like this:

  if (0) let
  x = 0

  Handling this edge case is useless but the behavior is required by the specification. However, that fix also unintentionally caused let to be considered an identifier in code like this:

  let
  x = 0

  In this case, let should be considered a keyword instead. This has been fixed.

• Fix some additional conformance tests

  Some additional syntax edge cases are now forbidden including let let, import {eval} from 'path', and if (1) x: function f() {}.

v0.7.4

比较 Source

• Undo an earlier change to try to improve yarn compatibility (#​91 and #​407)

  The yarn package manager behaves differently from npm and is not compatible in many ways. While npm is the only officially supported package manager for esbuild, people have contributed fixes for other package managers including yarn. One such fix is PR #​91 which makes sure the install script only runs once for a given installation directory.

  I suspect this fix is actually incorrect, and is the cause of issue #​407. The problem seems to be that if you change the version of a package using yarn add esbuild@version, yarn doesn't clear out the installation directory before reinstalling the package so the package ends up with a mix of files from both package versions. This is not how npm behaves and seems like a pretty severe bug in yarn. I am reverting PR #​91 in an attempt to fix this issue.

• Disable some warnings for code inside node_modules directories (#​395 and #​402)

  Using esbuild to build code with certain suspicious-looking syntax may generate a warning. These warnings don't fail the build (the build still succeeds) but they point out code that is very likely to not behave as intended. This has caught real bugs in the past:

  • rollup/rollup#​3729: Invalid dead code removal for return statement due to ASI

  • aws/aws-sdk-js#​3325: Array equality bug in the Node.js XML parser

  • olifolkerd/tabulator#​2962: Nonsensical comparisons with typeof and "null"

  • mrdoob/three.js#​11183: Comparison with -0 in Math.js

  • mrdoob/three.js#​11182: Cperator precedence bug in WWOBJLoader2.js

    However, it's not esbuild's job to find bugs in other libraries, and these warnings are problematic for people using these libraries with esbuild. The only fix is to either disable all esbuild warnings and not get warnings about your own code, or to try to get the warning fixed in the affected library. This is especially annoying if the warning is a false positive as was the case in https://github.com/firebase/firebase-js-sdk/issues/3814. So these warnings are now disabled for code inside `node_modules` directories.
    

v0.7.3

比较 Source

• Fix compile error due to missing unix.SYS_IOCTL in the latest golang.org/x/sys (#​396)

  The unix.SYS_IOCTL export was apparently removed from golang.org/x/sys recently, which affected code in esbuild that gets the width of the terminal. This code now uses another method of getting the terminal width. The fix was contributed by @​akayj.

• Validate that the versions of the host code and the binary executable match (#​407)

  After the install script runs, the version of the downloaded binary should always match the version of the package being installed. I have added some additional checks to verify this in case this invariant is ever broken. Breaking this invariant is very bad because it means the code being run is a mix of code from different package versions.

v0.7.2

比较 Source

• Add tsconfigRaw to the transform API (#​483)

  The build API uses access to the file system and doesn't run in the browser, but the transform API doesn't access the file system and can run in the browser. Previously you could only use the build API for certain scenarios involving TypeScript code and tsconfig.json files, such as configuring the importsNotUsedAsValues setting.

  You can now use tsconfig.json with the transform API by passing in the raw contents of that file:

  let result = esbuild.transformSync(ts, {
    loader: 'ts',
    tsconfigRaw: {
      compilerOptions: {
        importsNotUsedAsValues: 'preserve',
      },
    },
  })

  Right now four values are supported with the transform API: jsxFactory, jsxFragmentFactory, useDefineForClassFields, and importsNotUsedAsValues. The values extends, baseUrl, and paths are not supported because they require access to the file system and the transform API deliberately does not access the file system.

  You can also pass the tsconfig.json file as a string instead of a JSON object if you prefer. This can be useful because tsconfig.json files actually use a weird pseudo-JSON syntax that allows comments and trailing commas, which means it can't be parsed with JSON.parse().

• Warn about process.env.NODE_ENV

  Some popular browser-oriented libraries such as React use process.env.NODE_ENV even though this is not an API provided by the browser. While esbuild makes it easy to replace this at compile time using the --define feature, you must still do this manually and it's easy to forget. Now esbuild will warn you if you're bundling code containing process.env.NODE_ENV for the browser and you haven't configured it to be replaced by something.

• Work around a bug in Safari for the run-time code (#​489)

  The Object.getOwnPropertyDescriptor function in Safari is broken for numeric properties. It incorrectly returns undefined, which crashes the run-time code esbuild uses to bind modules together. This release contains code to avoid a crash in this case.

v0.7.1

比较 Source

• Add the --avoid-tdz option for large bundles in Safari (#​478)

  This is a workaround for a performance issue with certain large JavaScript files in Safari.

  First, some background. In JavaScript the var statement is "hoisted" meaning the variable is declared immediately in the closest surrounding function, module, or global scope. Accessing one of these variables before its declaration has been evaluated results in the value undefined. In ES6 the const, let, and class statements introduce what's called a "temporal dead zone" or TDZ. This means that, unlike var statements, accessing one of these variable before its declaration has been evaluated results in a ReferenceError being thrown. It's called a "temporal dead zone" because it's a zone of time in which the variable is inaccessible.

  According to this WebKit bug, there's a severe performance issue with the tracking of TDZ checks in JavaScriptCore, the JavaScript JIT compiler used by WebKit. In a large private code base I have access to, the initialization phase of the bundle produced by esbuild runs 10x faster in Safari if top-level const, let, and class are replaced with var. It's a difference between a loading time of about 2sec vs. about 200ms. This transformation is not enabled by default because it changes the semantics of the code (it removes the TDZ and const assignment checks). However, this change in semantics may be acceptable for you given the performance trade-off. You can enable it with the --avoid-tdz flag.

• Warn about assignment to const symbols

  Now that some const symbols may be converted to var due to --avoid-tdz, it seems like a good idea to at least warn when an assignment to a const symbol is detected during bundling. Otherwise accidental assignments to const symbols could go unnoticed if there isn't other tooling in place such as TypeScript or a linter.

v0.7.0

比较 Source

• Mark output files with a hashbang as executable (#​364)

  Output files that start with a hashbang line such as #!/usr/bin/env node will now automatically be marked as executable. This lets you run them directly in a Unix-like shell without using the node command.

• Use "main" for require() and "module" for import (#​363)

  The node module resolution algorithm uses the "main" field in package.json to determine which file to load when a package is loaded with require(). Independent of node, most bundlers have converged on a convention where the "module" field takes precedence over the "main" field when present. Package authors can then use the "module" field to publish the same code in a different format for bundlers than for node.

  This is commonly used to publish "dual packages" that appear to use ECMAScript modules to bundlers but that appear to use CommonJS modules to node. This is useful because ECMAScript modules improve bundler output by taking advantage of "tree shaking" (basically dead-code elimination) and because ECMAScript modules cause lots of problems in node (for example, node doesn't support importing ECMAScript modules using require()).

  The problem is that if code using require() resolves to the "module" field in esbuild, the resulting value is currently always an object. ECMAScript modules export a namespace containing all exported properties. There is no direct equivalent of module.exports = value in CommonJS. The closest is export default value but the CommonJS equivalent of that is exports.default = value. This is problematic for code containing module.exports = function() {} which is a frequently-used CommonJS library pattern. An example of such an issue is Webpack issue #​6584.

  An often-proposed way to fix this is to map require() to "main" and map import to "module". The problem with this is that it means the same package would be loaded into memory more than once if it is loaded both with require() and with import (perhaps from separate packages). An example of such an issue is GraphQL issue

---

Renovate 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 WhiteSource Renovate. View repository job log here.