vercel[bot]
commented
3 years ago This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.
next2 – ./packages/next2
🔍 Inspect: https://vercel.com/yurikrupnik/next2/7YpjKHuGPo8i8nCr86QMwYA7SjWL
✅ Preview: https://next2-git-renovate-esbuild-0x-yurikrupnik.vercel.app
next1 – ./packages/next1
🔍 Inspect: https://vercel.com/yurikrupnik/next1/9DGzw5zVQySriSoRVYHa5BpSLVjX
✅ Preview: https://next1-git-renovate-esbuild-0x-yurikrupnik.vercel.app
This PR contains the following updates:
0.11.21->0.11.23Release Notes
evanw/esbuild
### [`v0.11.23`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01123) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.11.22...v0.11.23) - Add a shim function for unbundled uses of `require` ([#1202](https://togithub.com/evanw/esbuild/issues/1202)) Modules in CommonJS format automatically get three variables injected into their scope: `module`, `exports`, and `require`. These allow the code to import other modules and to export things from itself. The bundler automatically rewrites uses of `module` and `exports` to refer to the module's exports and certain uses of `require` to a helper function that loads the imported module. Not all uses of `require` can be converted though, and un-converted uses of `require` will end up in the output. This is problematic because `require` is only present at run-time if the output is run as a CommonJS module. Otherwise `require` is undefined, which means esbuild's behavior is inconsistent between compile-time and run-time. The `module` and `exports` variables are objects at compile-time and run-time but `require` is a function at compile-time and undefined at run-time. This causes code that checks for `typeof require` to have inconsistent behavior: ```js 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 to `require` with a stub `__require` function when bundling if the output format is something other than CommonJS. This should ensure that `require` is now consistent between compile-time and run-time. When bundled, code that uses unbundled references to `require` will now look something like this: ```js 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](https://togithub.com/evanw/esbuild/issues/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). ### [`v0.11.22`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01122) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.11.21...v0.11.22) - Add support for the "import assertions" proposal This is new JavaScript syntax that was shipped in Chrome 91. It looks like this: ```js import './foo.json' assert { type: 'json' } import('./bar.json', { assert: { type: 'json' } }) ``` On the web, the content type for a given URL is determined by the `Content-Type` HTTP header instead of the file extension. So adding support for importing non-JS content types such as JSON to the web could cause [security issues](https://togithub.com/WICG/webcomponents/issues/839) since importing JSON from an untrusted source is safe while importing JS from an untrusted source is not. Import assertions are a new feature to address this security concern and unblock non-JS content types on the web. They cause the import to fail if the `Content-Type` header doesn't match the expected value. This prevents security issues for data-oriented content types such as JSON since it guarantees that data-oriented content will never accidentally be evaluated as code instead of data. More information about the proposal is available here: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.
This PR has been generated by WhiteSource Renovate. View repository job log here.