Snyk has created this PR to upgrade esbuild from 0.14.27 to 0.14.28.
: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 1 version ahead of your current version.
The recommended version was released 2 days ago, on 2022-03-26.
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}}
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.
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.
Snyk has created this PR to upgrade esbuild from 0.14.27 to 0.14.28.
Release notes
Package name: esbuild
-
0.14.28 - 2022-03-26
-
-
-
0.14.27 - 2022-03-14
-
-
from esbuild GitHub release notesAdd 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: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-wasmpackage 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.Avoid generating an enumerable
defaultimport 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
defaultimport is always set tomodule.exports, while in Babel mode thedefaultimport passes through tomodule.exports.defaultinstead. Node mode is triggered when the importing file ends in.mjs, hastype: "module"in itspackage.jsonfile, or the imported module does not have a__esModulemarker.Previously esbuild always created the forwarding
defaultimport in Babel mode, even ifmodule.exportshad no property calleddefault. This was problematic because the getter nameddefaultstill 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 nameddefaultwill now only be added in Babel mode if thedefaultproperty 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.exportsand 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
__esModulewhich 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__esModulethat 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.exportsobject 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 intorequire()calls). This release changesmodule.exportsinitialization 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.
Commit messages
Package name: esbuild
- 36c070e publish 0.14.28 to npm
- f71ae21 tag #2105 in changelog
- 517f77f work around go 1.18 wasm changes
- 2b48929 upgrade to go 1.18.0
- 648b072 fix #2117: support `@ font-feature-values`
- 2c3adfa css: fix parser recovery for rules without blocks
- cce4392 fix #2116: support `@ counter-style`
- 6fc8aa8 fix #2115: support `@ font-palette-values`
- 2296f46 Fix make clean (#2106)
- 255a22f fix "__name" removal bug with lowered classes
CompareNote: 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