search

Naila / Discord-chat-replica

Open Software License 3.0
24 stars 15 forks source link

Bump esbuild from 0.8.57 to 0.14.28 #132

Closed dependabot[bot] closed 2 years ago

dependabot[bot] commented 2 years ago

Bumps esbuild from 0.8.57 to 0.14.28.

Release notes

Sourced from esbuild's releases.

v0.14.28

  • Add support for some new CSS rules (#2115, #2116, #2117)

    This release adds support for @font-palette-values, @counter-style, and @font-feature-values. This means esbuild will now pretty-print and minify these rules better since it now better understands the internal structure of these rules:

    /* Original code */
@font-palette-values Foo { base-palette: 1; }
@counter-style bar { symbols: b a r; }
@font-feature-values Bop { @styleset { test: 1; } }

    /* Old output (with --minify) */
@​font-palette-values Foo{base-palette: 1;}@​counter-style bar{symbols: b a r;}@​font-feature-values Bop{@​styleset {test: 1;}}
    

    /* New output (with --minify) */
@​font-palette-values Foo{base-palette:1}@​counter-style bar{symbols:b a r}@​font-feature-values Bop{@​styleset{test:1}}

  • Upgrade to Go 1.18.0 (#2105)

    Binary executables for this version are now published with Go version 1.18.0. The Go release notes say that the linker generates smaller binaries and that on 64-bit ARM chips, compiled binaries run around 10% faster. On an M1 MacBook Pro, esbuild's benchmark runs approximately 8% faster than before and the binary executable is approximately 4% smaller than before.

    This also fixes a regression from version 0.14.26 of esbuild where the browser builds of the esbuild-wasm package could fail to be bundled due to the use of built-in node libraries. The primary WebAssembly shim for Go 1.18.0 no longer uses built-in node libraries.

v0.14.27

  • Avoid generating an enumerable default import for CommonJS files in Babel mode (#2097)

    Importing a CommonJS module into an ES module can be done in two different ways. In node mode the default import is always set to module.exports, while in Babel mode the default import passes through to module.exports.default instead. Node mode is triggered when the importing file ends in .mjs, has type: "module" in its package.json file, or the imported module does not have a __esModule marker.

    Previously esbuild always created the forwarding default import in Babel mode, even if module.exports had no property called default. This was problematic because the getter named default still showed up as a property on the imported namespace object, and could potentially interfere with code that iterated over the properties of the imported namespace object. With this release the getter named default will now only be added in Babel mode if the default property exists at the time of the import.

  • Fix a circular import edge case regarding ESM-to-CommonJS conversion (#1894, #2059)

    This fixes a regression that was introduced in version 0.14.5 of esbuild. Ever since that version, esbuild now creates two separate export objects when you convert an ES module file into a CommonJS module: one for ES modules and one for CommonJS modules. The one for CommonJS modules is written to module.exports and exported from the file, and the one for ES modules is internal and can be accessed by bundling code that imports the entry point (for example, the entry point might import itself to be able to inspect its own exports).

    The reason for these two separate export objects is that CommonJS modules are supposed to see a special export called __esModule which indicates that the module used to be an ES module, while ES modules are not supposed to see any automatically-added export named __esModule. This matters for real-world code both because people sometimes iterate over the properties of ES module export namespace objects and because some people write ES module code containing their own exports named __esModule that they expect other ES module code to be able to read.

    However, this change to split exports into two separate objects broke ES module re-exports in the edge case where the imported module is involved in an import cycle. This happened because the CommonJS module.exports object was no longer mutated as exports were added. Instead it was being initialized at the end of the generated file after the import statements to other modules (which are converted into require() calls). This release changes module.exports initialization to happen earlier in the file and then double-writes further exports to both the ES module and CommonJS module export objects.

    This fix was contributed by @​indutny.

v0.14.26

  • Fix a tree shaking regression regarding var declarations (#2080, #2085, #2098, #2099)

    Version 0.14.8 of esbuild enabled removal of duplicate function declarations when minification is enabled (see #610):

    // Original code
function x() { return 1 }
console.log(x())

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.28

  • Add support for some new CSS rules (#2115, #2116, #2117)

    This release adds support for @font-palette-values, @counter-style, and @font-feature-values. This means esbuild will now pretty-print and minify these rules better since it now better understands the internal structure of these rules:

    /* Original code */
@font-palette-values Foo { base-palette: 1; }
@counter-style bar { symbols: b a r; }
@font-feature-values Bop { @styleset { test: 1; } }

    /* Old output (with --minify) */
@​font-palette-values Foo{base-palette: 1;}@​counter-style bar{symbols: b a r;}@​font-feature-values Bop{@​styleset {test: 1;}}
    

    /* New output (with --minify) */
@​font-palette-values Foo{base-palette:1}@​counter-style bar{symbols:b a r}@​font-feature-values Bop{@​styleset{test:1}}

  • Upgrade to Go 1.18.0 (#2105)

    Binary executables for this version are now published with Go version 1.18.0. The Go release notes say that the linker generates smaller binaries and that on 64-bit ARM chips, compiled binaries run around 10% faster. On an M1 MacBook Pro, esbuild's benchmark runs approximately 8% faster than before and the binary executable is approximately 4% smaller than before.

    This also fixes a regression from version 0.14.26 of esbuild where the browser builds of the esbuild-wasm package could fail to be bundled due to the use of built-in node libraries. The primary WebAssembly shim for Go 1.18.0 no longer uses built-in node libraries.

0.14.27

  • Avoid generating an enumerable default import for CommonJS files in Babel mode (#2097)

    Importing a CommonJS module into an ES module can be done in two different ways. In node mode the default import is always set to module.exports, while in Babel mode the default import passes through to module.exports.default instead. Node mode is triggered when the importing file ends in .mjs, has type: "module" in its package.json file, or the imported module does not have a __esModule marker.

    Previously esbuild always created the forwarding default import in Babel mode, even if module.exports had no property called default. This was problematic because the getter named default still showed up as a property on the imported namespace object, and could potentially interfere with code that iterated over the properties of the imported namespace object. With this release the getter named default will now only be added in Babel mode if the default property exists at the time of the import.

  • Fix a circular import edge case regarding ESM-to-CommonJS conversion (#1894, #2059)

    This fixes a regression that was introduced in version 0.14.5 of esbuild. Ever since that version, esbuild now creates two separate export objects when you convert an ES module file into a CommonJS module: one for ES modules and one for CommonJS modules. The one for CommonJS modules is written to module.exports and exported from the file, and the one for ES modules is internal and can be accessed by bundling code that imports the entry point (for example, the entry point might import itself to be able to inspect its own exports).

    The reason for these two separate export objects is that CommonJS modules are supposed to see a special export called __esModule which indicates that the module used to be an ES module, while ES modules are not supposed to see any automatically-added export named __esModule. This matters for real-world code both because people sometimes iterate over the properties of ES module export namespace objects and because some people write ES module code containing their own exports named __esModule that they expect other ES module code to be able to read.

    However, this change to split exports into two separate objects broke ES module re-exports in the edge case where the imported module is involved in an import cycle. This happened because the CommonJS module.exports object was no longer mutated as exports were added. Instead it was being initialized at the end of the generated file after the import statements to other modules (which are converted into require() calls). This release changes module.exports initialization to happen earlier in the file and then double-writes further exports to both the ES module and CommonJS module export objects.

    This fix was contributed by @​indutny.

0.14.26

  • Fix a tree shaking regression regarding var declarations (#2080, #2085, #2098, #2099)

    Version 0.14.8 of esbuild enabled removal of duplicate function declarations when minification is enabled (see #610):

... (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 #133.