esbuild 0.11.23
-
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 ofmoduleandexportsto refer to the module's exports and certain uses ofrequireto a helper function that loads the imported module.Not all uses of
requirecan be converted though, and un-converted uses ofrequirewill end up in the output. This is problematic becauserequireis only present at run-time if the output is run as a CommonJS module. Otherwiserequireis undefined, which means esbuild's behavior is inconsistent between compile-time and run-time. Themoduleandexportsvariables are objects at compile-time and run-time butrequireis a function at compile-time and undefined at run-time. This causes code that checks fortypeof requireto have inconsistent behavior:if (typeof require === 'function' && typeof exports === 'object' && typeof module === 'object') { console.log('CommonJS detected') }In the above example, ideally
CommonJS detectedwould always be printed since the code is being bundled with a CommonJS-aware bundler. To fix this, esbuild will now substitute references torequirewith a stub__requirefunction when bundling if the output format is something other than CommonJS. This should ensure thatrequireis now consistent between compile-time and run-time. When bundled, code that uses unbundled references torequirewill 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).