-
Add a shim function for unbundled uses of
require
(#1202)Modules in CommonJS format automatically get three variables injected into their scope:
module
,exports
, andrequire
. These allow the code to import other modules and to export things from itself. The bundler automatically rewrites uses ofmodule
andexports
to refer to the module's exports and certain uses ofrequire
to a helper function that loads the imported module.Not all uses of
require
can be converted though, and un-converted uses ofrequire
will end up in the output. This is problematic becauserequire
is only present at run-time if the output is run as a CommonJS module. Otherwiserequire
is undefined, which means esbuild's behavior is inconsistent between compile-time and run-time. Themodule
andexports
variables are objects at compile-time and run-time butrequire
is a function at compile-time and undefined at run-time. This causes code that checks fortypeof require
to have inconsistent behavior:if (typeof require === 'function' && typeof exports === 'object' && typeof module === 'object') { console.log('CommonJS detected') }
In the above example, ideally
CommonJS detected
would always be printed since the code is being bundled with a CommonJS-aware bundler. To fix this, esbuild will now substitute references torequire
with a stub__require
function when bundling if the output format is something other than CommonJS. This should ensure thatrequire
is now consistent between compile-time and run-time. When bundled, code that uses unbundled references torequire
will now look something like this:var __require = (x) => { if (typeof require !== "undefined") return require(x); throw new Error('Dynamic require of "' + x + '" is not supported'); }; var __commonJS = (cb, mod) => () => (mod || cb((mod = {exports: {}}).exports, mod), mod.exports); var require_example = __commonJS((exports, module) => { if (typeof __require === "function" && typeof exports === "object" && typeof module === "object") { console.log("CommonJS detected"); } }); require_example();
-
Fix incorrect caching of internal helper function library (#1292)
This release fixes a bug where running esbuild multiple times with different configurations sometimes resulted in code that would crash at run-time. The bug was introduced in version 0.11.19 and happened because esbuild's internal helper function library is parsed once and cached per configuration, but the new profiler name option was accidentally not included in the cache key. This option is now included in the cache key so this bug should now be fixed.
-
Minor performance improvements
This release contains some small performance improvements to offset an earlier minor performance regression due to the addition of certain features such as hashing for entry point files. The benchmark times on the esbuild website should now be accurate again (versions of esbuild after the regression but before this release were slightly slower than the benchmark).