chore(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	^0.14.38 -> ^0.14.43
magic-string	^0.26.1 -> ^0.26.2
pathe	^0.2.0 -> ^0.3.0
pnpm (source)	7.0.0 -> 7.2.0
rollup (source)	^2.71.1 -> ^2.75.6
rollup-plugin-dts	^4.2.1 -> ^4.2.2
typescript (source)	^4.6.4 -> ^4.7.3

---

Release Notes

evanw/esbuild

v0.14.43

Compare Source

• Fix TypeScript parse error whe a generic function is the first type argument (#​2306)

  In TypeScript, the << token may need to be split apart into two < tokens if it's present in a type argument context. This was already correctly handled for all type expressions and for identifier expressions such as in the following code:

  // These cases already worked in the previous release
  let foo: Array<<T>() => T>;
  bar<<T>() => T>;

  However, normal expressions of the following form were previously incorrectly treated as syntax errors:

  // These cases were broken but have now been fixed
  foo.bar<<T>() => T>;
  foo?.<<T>() => T>();

  With this release, these cases now parsed correctly.

• Fix minification regression with pure IIFEs (#​2279)

  An Immediately Invoked Function Expression (IIFE) is a function call to an anonymous function, and is a way of introducing a new function-level scope in JavaScript since JavaScript lacks a way to do this otherwise. And a pure function call is a function call with the special /* @​__PURE__ */ comment before it, which tells JavaScript build tools that the function call can be considered to have no side effects (and can be removed if it's unused).

  Version 0.14.9 of esbuild introduced a regression that changed esbuild's behavior when these two features were combined. If the IIFE body contains a single expression, the resulting output still contained that expression instead of being empty. This is a minor regression because you normally wouldn't write code like this, so this shouldn't come up in practice, and it doesn't cause any correctness issues (just larger-than-necessary output). It's unusual that you would tell esbuild "remove this if the result is unused" and then not store the result anywhere, since the result is unused by construction. But regardless, the issue has now been fixed.

  For example, the following code is a pure IIFE, which means it should be completely removed when minification is enabled. Previously it was replaced by the contents of the IIFE but it's now completely removed:

  // Original code
  /* @​__PURE__ */ (() => console.log(1))()
  
  // Old output (with --minify)
  console.log(1);
  
  // New output (with --minify)

• Add log messages for indirect require references (#​2231)

  A long time ago esbuild used to warn about indirect uses of require because they break esbuild's ability to analyze the dependencies of the code and cause dependencies to not be bundled, resulting in a potentially broken bundle. However, this warning was removed because many people wanted the warning to be removed. Some packages have code that uses require like this but on a code path that isn't used at run-time, so their code still happens to work even though the bundle is incomplete. For example, the following code will not bundle bindings:

  // Prevent React Native packager from seeing modules required with this
  const nodeRequire = require;
  
  function getRealmConstructor(environment) {
    switch (environment) {
      case "node.js":
      case "electron":
        return nodeRequire("bindings")("realm.node").Realm;
    }
  }

  Version 0.11.11 of esbuild removed this warning, which means people no longer have a way to know at compile time whether their bundle is broken in this way. Now that esbuild has custom log message levels, this warning can be added back in a way that should make both people happy. With this release, there is now a log message for this that defaults to the debug log level, which normally isn't visible. You can either do --log-override:indirect-require=warning to make this log message a warning (and therefore visible) or use --log-level=debug to see this and all other debug log messages.

v0.14.42

Compare Source

• Fix a parser hang on invalid CSS (#​2276)

  Previously invalid CSS with unbalanced parentheses could cause esbuild's CSS parser to hang. An example of such an input is the CSS file :x(. This hang has been fixed.

• Add support for custom log message levels

  This release allows you to override the default log level of esbuild's individual log messages. For example, CSS syntax errors are treated as warnings instead of errors by default because CSS grammar allows for rules containing syntax errors to be ignored. However, if you would like for esbuild to consider CSS syntax errors to be build errors, you can now configure that like this:

  • CLI

    $ esbuild example.css --log-override:css-syntax-error=error

  • JS API

    let result = await esbuild.build({
      entryPoints: ['example.css'],
      logOverride: {
        'css-syntax-error': 'error',
      },
    })

  • Go API

    result := api.Build(api.BuildOptions{
      EntryPoints: []string{"example.ts"},
      LogOverride: map[string]api.LogLevel{
        "css-syntax-error": api.LogLevelError,
      },
    })

  You can also now use this feature to silence warnings that you are not interested in. Log messages are referred to by their identifier. Each identifier is stable (i.e. shouldn't change over time) except there is no guarantee that the log message will continue to exist. A given log message may potentially be removed in the future, in which case esbuild will ignore log levels set for that identifier. The current list of supported log level identifiers for use with this feature can be found below:

  JavaScript:

  • assign-to-constant
  • call-import-namespace
  • commonjs-variable-in-esm
  • delete-super-property
  • direct-eval
  • duplicate-case
  • duplicate-object-key
  • empty-import-meta
  • equals-nan
  • equals-negative-zero
  • equals-new-object
  • html-comment-in-js
  • impossible-typeof
  • private-name-will-throw
  • semicolon-after-return
  • suspicious-boolean-not
  • this-is-undefined-in-esm
  • unsupported-dynamic-import
  • unsupported-jsx-comment
  • unsupported-regexp
  • unsupported-require-call

  CSS:

  • css-syntax-error
  • invalid-@​charset
  • invalid-@​import
  • invalid-@​nest
  • invalid-@​layer
  • invalid-calc
  • js-comment-in-css
  • unsupported-@​charset
  • unsupported-@​namespace
  • unsupported-css-property

  Bundler:

  • different-path-case
  • ignored-bare-import
  • ignored-dynamic-import
  • import-is-undefined
  • package.json
  • require-resolve-not-external
  • tsconfig.json

  Source maps:

  • invalid-source-mappings
  • sections-in-source-map
  • missing-source-map
  • unsupported-source-map-comment

  Documentation about which identifiers correspond to which log messages will be added in the future, but hasn't been written yet. Note that it's not possible to configure the log level for a build error. This is by design because changing that would cause esbuild to incorrectly proceed in the building process generate invalid build output. You can only configure the log level for non-error log messages (although you can turn non-errors into errors).

v0.14.41

Compare Source

• Fix a minification regression in 0.14.40 (#​2270, #​2271, #​2273)

  Version 0.14.40 substituted string property keys with numeric property keys if the number has the same string representation as the original string. This was done in three places: computed member expressions, object literal properties, and class fields. However, negative numbers are only valid in computed member expressions while esbuild incorrectly applied this substitution for negative numbers in all places. This release fixes the regression by only doing this substitution for negative numbers in computed member expressions.

  This fix was contributed by @​susiwen8.

v0.14.40

Compare Source

• Correct esbuild's implementation of "preserveValueImports": true (#​2268)

  TypeScript's preserveValueImports setting tells the compiler to preserve unused imports, which can sometimes be necessary because otherwise TypeScript will remove unused imports as it assumes they are type annotations. This setting is useful for programming environments that strip TypeScript types as part of a larger code transformation where additional code is appended later that will then make use of those unused imports, such as with Svelte or Vue.

  This release fixes an issue where esbuild's implementation of preserveValueImports diverged from the official TypeScript compiler. If the import clause is present but empty of values (even if it contains types), then the import clause should be considered a type-only import clause. This was an oversight, and has now been fixed:

  // Original code
  import "keep"
  import { k1 } from "keep"
  import k2, { type t1 } from "keep"
  import {} from "remove"
  import { type t2 } from "remove"
  
  // Old output under "preserveValueImports": true
  import "keep";
  import { k1 } from "keep";
  import k2, {} from "keep";
  import {} from "remove";
  import {} from "remove";
  
  // New output under "preserveValueImports": true (matches the TypeScript compiler)
  import "keep";
  import { k1 } from "keep";
  import k2 from "keep";

• Avoid regular expression syntax errors in older browsers (#​2215)

  Previously esbuild always passed JavaScript regular expression literals through unmodified from the input to the output. This is undesirable when the regular expression uses newer features that the configured target environment doesn't support. For example, the d flag (i.e. the match indices feature) is new in ES2022 and doesn't work in older browsers. If esbuild generated a regular expression literal containing the d flag, then older browsers would consider esbuild's output to be a syntax error and none of the code would run.

  With this release, esbuild now detects when an unsupported feature is being used and converts the regular expression literal into a new RegExp() constructor instead. One consequence of this is that the syntax error is transformed into a run-time error, which allows the output code to run (and to potentially handle the run-time error). Another consequence of this is that it allows you to include a polyfill that overwrites the RegExp constructor in older browsers with one that supports modern features. Note that esbuild does not handle polyfills for you, so you will need to include a RegExp polyfill yourself if you want one.

  // Original code
  console.log(/b/d.exec('abc').indices)
  
  // New output (with --target=chrome90)
  console.log(/b/d.exec("abc").indices);
  
  // New output (with --target=chrome89)
  console.log(new RegExp("b", "d").exec("abc").indices);

  This is currently done transparently without a warning. If you would like to debug this transformation to see where in your code esbuild is transforming regular expression literals and why, you can pass --log-level=debug to esbuild and review the information present in esbuild's debug logs.

• Add Opera to more internal feature compatibility tables (#​2247, #​2252)

  The internal compatibility tables that esbuild uses to determine which environments support which features are derived from multiple sources. Most of it is automatically derived from these ECMAScript compatibility tables, but missing information is manually copied from MDN, GitHub PR comments, and various other websites. Version 0.14.35 of esbuild introduced Opera as a possible target environment which was automatically picked up by the compatibility table script, but the manually-copied information wasn't updated to include Opera. This release fixes this omission so Opera feature compatibility should now be accurate.

  This was contributed by @​lbwa.

• Ignore EPERM errors on directories (#​2261)

  Previously bundling with esbuild when inside a sandbox environment which does not have permission to access the parent directory did not work because esbuild would try to read the directory to search for a node_modules folder and would then fail the build when that failed. In practice this caused issues with running esbuild with sandbox-exec on macOS. With this release, esbuild will treat directories with permission failures as empty to allow for the node_modules search to continue past the denied directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations. This fix is similar to the fix in version 0.9.1 but is for EPERM while that fix was for EACCES.

• Remove an irrelevant extra "use strict" directive (#​2264)

  The presence of a "use strict" directive in the output file is controlled by the presence of one in the entry point. However, there was a bug that would include one twice if the output format is ESM. This bug has been fixed.

• Minify strings into integers inside computed properties (#​2214)

  This release now minifies a["0"] into a[0] when the result is equivalent:

  // Original code
  console.log(x['0'], { '0': x }, class { '0' = x })
  
  // Old output (with --minify)
  console.log(x["0"],{"0":x},class{"0"=x});
  
  // New output (with --minify)
  console.log(x[0],{0:x},class{0=x});

  This transformation currently only happens when the numeric property represents an integer within the signed 32-bit integer range.

v0.14.39

Compare Source

• Fix code generation for export default and /* @​__PURE__ */ call (#​2203)

  The /* @​__PURE__ */ comment annotation can be added to function calls to indicate that they are side-effect free. These annotations are passed through into the output by esbuild since many JavaScript tools understand them. However, there was an edge case where printing this comment before a function call caused esbuild to fail to parenthesize a function literal because it thought it was no longer at the start of the expression. This problem has been fixed:

  // Original code
  export default /* @​__PURE__ */ (function() {
  })()
  
  // Old output
  export default /* @​__PURE__ */ function() {
  }();
  
  // New output
  export default /* @​__PURE__ */ (function() {
  })();

• Preserve ... before JSX child expressions (#​2245)

  TypeScript 4.5 changed how JSX child expressions that start with ... are emitted. Previously the ... was omitted but starting with TypeScript 4.5, the ... is now preserved instead. This release updates esbuild to match TypeScript's new output in this case:

  // Original code
  console.log(<a>{...b}</a>)
  
  // Old output
  console.log(/* @&#8203;__PURE__ */ React.createElement("a", null, b));
  
  // New output
  console.log(/* @&#8203;__PURE__ */ React.createElement("a", null, ...b));

  Note that this behavior is TypeScript-specific. Babel doesn't support the ... token at all (it gives the error "Spread children are not supported in React").

• Slightly adjust esbuild's handling of the browser field in package.json (#​2239)

  This release changes esbuild's interpretation of browser path remapping to fix a regression that was introduced in esbuild version 0.14.21. Browserify has a bug where it incorrectly matches package paths to relative paths in the browser field, and esbuild replicates this bug for compatibility with Browserify. I have a set of tests that I use to verify that esbuild's replication of this Browserify is accurate here: https://github.com/evanw/package-json-browser-tests. However, I was missing a test case and esbuild's behavior diverges from Browserify in this case. This release now handles this edge case as well:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

    {
      "browser": {
        "./sub": "./sub/foo.js",
        "./sub/sub.js": "./sub/foo.js"
      }
    }

  • node_modules/pkg/sub/foo.js:

    require('sub')

  • node_modules/sub/index.js:

    console.log('works')

  The import path sub in require('sub') was previously matching the remapping "./sub/sub.js": "./sub/foo.js" but with this release it should now no longer match that remapping. Now require('sub') will only match the remapping "./sub/sub": "./sub/foo.js" (without the trailing .js). Browserify apparently only matches without the .js suffix here.

rich-harris/magic-string

v0.26.2

Compare Source

Bug Fixes

• specify types in exports (#​214) (985e7b4)

pnpm/pnpm

v7.2.0

Compare Source

Minor Changes

• A new setting is supported for ignoring specific deprecation messages: pnpm.allowedDeprecatedVersions. The setting should be provided in the pnpm section of the root package.json file. The below example will mute any deprecation warnings about the request package and warnings about express v1:

  {
    "pnpm": {
      "allowedDeprecatedVersions": {
        "request": "*",
        "express": "1"
      }
    }
  }

  Related issue: #​4306
  Related PR: #​4864

Patch Changes

• Update the compatibility database.
• Report only the first occurrence of a deprecated package.
• Add better hints to the peer dependency issue errors.

Our Sponsors

#### What's Changed * fix(setup): use @​pnpm/os.env.path-extender by @​zkochan in https://github.com/pnpm/pnpm/pull/4862 * fix: don't report the same deprecated package multiple times by @​zkochan in https://github.com/pnpm/pnpm/pull/4863 * feat: allowed deprecated versions by @​zkochan in https://github.com/pnpm/pnpm/pull/4864 * fix: add better peer dep error hints by @​zkochan in https://github.com/pnpm/pnpm/pull/4875

Full Changelog: pnpm/pnpm@v7.1.9...v7.2.0

v7.1.9

Compare Source

Patch Changes

• When the same package is found several times in the dependency graph, correctly autoinstall its missing peer dependencies at all times #​4820.

Our Sponsors

#### What's Changed * fix: auto-install-peers by @​zkochan in https://github.com/pnpm/pnpm/pull/4855

Full Changelog: pnpm/pnpm@v7.1.8...v7.1.9

v7.1.8

Compare Source

Patch Changes

• Suggest updating using Corepack, when pnpm was installed via Corepack.
• It should be possible to install a git-hosted package that has no package.json file #​4822.
• Fix pre-compiled pnpm binaries crashing when NODE_MODULES is set.

Our Sponsors

#### What's Changed * fix: pnpm pre-compiled binaries crash when NODE_MODULES is set by @​gluxon in https://github.com/pnpm/pnpm/pull/4823 * refactor(lockfile-file): Abstract LockfileFile to Lockfile conversion by @​gluxon in https://github.com/pnpm/pnpm/pull/4824 * test: update Jest by @​zkochan in https://github.com/pnpm/pnpm/pull/4644 * fix(cli): suggest to update with Corepack by @​zkochan in https://github.com/pnpm/pnpm/pull/4854 * fix: resolve manifest promise when manifest is not found by @​zkochan in https://github.com/pnpm/pnpm/pull/4826

Full Changelog: pnpm/pnpm@v7.1.7...v7.1.8

v7.1.7

Compare Source

Patch Changes

• Improve the performance of the build sequence calculation step #​4815.
• Correctly detect repeated dependency sequence during resolution #​4813.

Our Sponsors

##### What's Changed * fix: `pnpm add @​teambit/bit` should succeed by @​zkochan in https://github.com/pnpm/pnpm/pull/4813 * perf: build-modules by @​zkochan in https://github.com/pnpm/pnpm/pull/4815

Full Changelog: pnpm/pnpm@v7.1.6...v7.1.7

v7.1.6

Compare Source

Patch Changes

• Don't fail on projects with linked dependencies, when auto-install-peers is set to true #​4796.
• NODE_ENV=production pnpm install --dev should only install dev deps #​4745.

Our Sponsors

#### What's Changed * fix: only devDependencies are installed regardless of the node env by @​Spencer17x in https://github.com/pnpm/pnpm/pull/4805 * fix(auto-install-peers): don't fail on projects with linked deps by @​zkochan in https://github.com/pnpm/pnpm/pull/4807

Full Changelog: pnpm/pnpm@v7.1.5...v7.1.6

v7.1.5

Compare Source

Patch Changes

• Correctly detect the active Node.js version, when the pnpm CLI is bundled to an executable #​4203.

Our Sponsors

Full Changelog: pnpm/pnpm@v7.1.4...v7.1.5

v7.1.4

Compare Source

Patch Changes

• Correctly detect the active Node.js version, when the pnpm CLI is bundled to an executable #​4203.

Our Sponsors

#### What's Changed * fix: correctly detect the active Node.js version by @​zkochan in https://github.com/pnpm/pnpm/pull/4780

Full Changelog: pnpm/pnpm@v7.1.3...v7.1.4

v7.1.3

Compare Source

Patch Changes

• When auto-install-peers is set to true, automatically install missing peer dependencies without writing them to package.json as dependencies. This makes pnpm handle peer dependencies the same way as npm v7 #​4776.

Our Sponsors

#### What's Changed * chore: renovate bot setting to pin actions to a full length commit SHA by @​naveensrinivasan in https://github.com/pnpm/pnpm/pull/4768 * feat: auto install peer dependencies by @​zkochan in https://github.com/pnpm/pnpm/pull/4776 #### New Contributors * @​naveensrinivasan made their first contribution in https://github.com/pnpm/pnpm/pull/4768

Full Changelog: pnpm/pnpm@v7.1.2...v7.1.3

v7.1.2

Compare Source

Patch Changes

• pnpm setup should not fail on Windows if PNPM_HOME is not yet in the system registry #​4757
• pnpm dlx shouldn't modify the lockfile in the current working directory #​4743.

Our Sponsors

#### What's Changed * fix(setup): don't fail if PNPM_HOME is not yet in the system registry by @​zkochan in https://github.com/pnpm/pnpm/pull/4760 * fix(dlx): do not modify the lockfile in the cwd by @​zkochan in https://github.com/pnpm/pnpm/pull/4762

Full Changelog: pnpm/pnpm@v7.1.1...v7.1.2

v7.1.1

Compare Source

Patch Changes

• When the global bin directory is set to a symlink, check not only the symlink in the PATH but also the target of the symlink #​4744.
• Sanitize the directory names created inside node_modules/.pnpm and inside the global store #​4716
• All arguments after pnpm create <pkg> should be passed to the executed create app package. So pnpm create next-app --typescript should work`.
• Resolve commits from GitHub via https #​4734.

Our Sponsors

#### What's Changed * fix: sanitize dir names in the store by @​zkochan in https://github.com/pnpm/pnpm/pull/4726 * fix(create): pass all args to the executed create-app pkg by @​zkochan in https://github.com/pnpm/pnpm/pull/4730 * fix(git-resolver): resolve commits via https by @​zkochan in https://github.com/pnpm/pnpm/pull/4734 * refactor: setup by @​zkochan in https://github.com/pnpm/pnpm/pull/4731 * fix(config): checking global-bin-dir in PATH by @​zkochan in https://github.com/pnpm/pnpm/pull/4751

Full Changelog: pnpm/pnpm@v7.1.0...v7.1.1

v7.1.0

Compare Source

Minor Changes

• Added support for libc field in package.json #​4454.

Patch Changes

• pnpm setup should update the config of the current shell, not the preferred shell.
• pnpm setup should not override the PNPM_HOME env variable, unless --force is used.
• pnpm dlx should print messages about installation to stderr #​1698.
• pnpm dlx should work with git-hosted packages. For example: pnpm dlx gengjiawen/envinfo #​4714.
• pnpm run --stream should prefix the output with directory #​4702

Our Sponsors

#### What's Changed * fix(dlx): print install output to stderr by @​zkochan in https://github.com/pnpm/pnpm/pull/4696 * fix: `pnpm setup` breaks PATH with non-ascii characters by @​liuxingbaoyu in https://github.com/pnpm/pnpm/pull/4699 * fix(setup): update the current shell, not the preferred one by @​zkochan in https://github.com/pnpm/pnpm/pull/4701 * refactor: use @​yarnpkg/extensions instead of @​yarnpkg/plugin-compat by @​zkochan in https://github.com/pnpm/pnpm/pull/4710 * Refactor setup by @​zkochan in https://github.com/pnpm/pnpm/pull/4709 * pnpm run --stream should prefix with dir name by @​kenrick95 in https://github.com/pnpm/pnpm/pull/4703 * feat: support libc field for package.json by @​fireairforce in https://github.com/pnpm/pnpm/pull/4605 * fix: make `pnpm setup` free of garbled characters by @​liuxingbaoyu in https://github.com/pnpm/pnpm/pull/4712 * fix(dlx): pnpm dlx should work with git-hosted pkgs by @​zkochan in https://github.com/pnpm/pnpm/pull/4717 * refactor: pnpm setup by @​zkochan in https://github.com/pnpm/pnpm/pull/4713 #### New Contributors * @​liuxingbaoyu made their first contribution in https://github.com/pnpm/pnpm/pull/4699

Full Changelog: pnpm/pnpm@v7.0.1...v7.1.0

v7.0.1

Compare Source

Patch Changes

• Use Yarn's compatibility database to patch broken packages in the ecosystem with package extensions #​4676.
• pnpm dlx should work when the bin name of the executed package isn't the same as the package name #​4672.
• Throw an error if arguments are passed to the pnpm init command #​4665.
• pnpm prune works in a workspace #​4647.
• Do not report request retry warnings when loglevel is set to error #​4669.
• pnpm prune does not remove hoisted dependencies #​4647.

Our Sponsors

#### New Contributors * @​axe-me made their first contribution in https://github.com/pnpm/pnpm/pull/4654

Full Changelog: pnpm/pnpm@v7.0.0...v7.0.1

rollup/rollup

v2.75.6

Compare Source

2022-06-07

Bug Fixes

• Properly deoptimize "this" when using member expressions with getters/setters in for loops and update expressions (#​4522)

Pull Requests

• #​4522: Refactor side effect handling for property interactions (@​lukastaegert)

v2.75.5

Compare Source

2022-06-01

Bug Fixes

• Avoid crashes when using logical expressions for unused constructor arguments (#​4519)
• Fix missing parameter defaults for calls from try statements and functions returned by functions (#​4520)

Pull Requests

• #​4519: Try to make logical expression deoptimization more robust (@​lukastaegert)
• #​4520: Roll back parameter default tree shaking (@​lukastaegert)

v2.75.4

Compare Source

2022-05-31

Bug Fixes

• Ensure parameter defaults are retained when a function is used as an object property (#​4516)

Pull Requests

• #​4516: Deoptimize parameter defaults when referenced from object/array/class literals (@​lukastaegert)

v2.75.3

Compare Source

2022-05-29

Bug Fixes

• Retain parameter defaults for functions that are defaults themselves (#​4515)
• Track mutations for objects as default values (#​4515)

Pull Requests

• #​4515: Ensure parameter defaults are deoptimized (@​lukastaegert)

v2.75.2

Compare Source

v2.75.1

Compare Source

2022-05-28

Pull Requests

• #​4513: Update link to node polyfill repo (@​lukastaegert)

v2.75.0

Compare Source

2022-05-27

Features

• Re-implement default parameter tree-shaking for top-level functions (#​4510)
• Do not consider calling string methods like .trim() on template literals a side effect (#​4511)

Pull Requests

• #​4510: Tree-shake parameter defaults (replaces #​4498) (@​lukastaegert)
• #​4511: Tree-shake side-effect-free string methods on template literals (@​lukastaegert)

v2.74.1

Compare Source

2022-05-19

Bug Fixes

• Revert #​4498 until some issues are understood and resolved

v2.74.0

Compare Source

2022-05-19

Features

• Remove unneeded default values for function parameters (#​4498)

Bug Fixes

• Use a consistent mechanism to resolve the config file to avoid issues on Windows (#​4501)
• Avoid an inaccurate warning about an event emitter leak for complicated builds (#​4502)
• Ensure that reexporting values from other chunks via dynamic imports does not reference non-imported variables ([#​4499](https://togithub.com/rollup/rollup/i

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - 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.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, click this checkbox.

---

This PR has been generated by Mend Renovate. View repository job log here.