build: update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@babel/core (source)	7.16.0 -> 7.16.5
@babel/generator (source)	7.16.0 -> 7.16.5
@babel/plugin-proposal-async-generator-functions (source)	7.16.4 -> 7.16.5
@babel/plugin-transform-async-to-generator (source)	7.16.0 -> 7.16.5
@babel/plugin-transform-runtime (source)	7.16.4 -> 7.16.5
@babel/preset-env (source)	7.16.4 -> 7.16.5
@babel/runtime (source)	7.16.3 -> 7.16.5
@typescript-eslint/eslint-plugin	5.6.0 -> 5.7.0
esbuild	0.14.3 -> 0.14.5
esbuild-wasm	0.14.3 -> 0.14.5

---

Release Notes

babel/babel

v7.16.5

Compare Source

👓 Spec Compliance

• babel-cli, babel-core, babel-helpers, babel-plugin-proposal-class-properties, babel-plugin-proposal-decorators, babel-plugin-transform-classes, babel-plugin-transform-jscript, babel-plugin-transform-parameters, babel-plugin-transform-runtime, babel-plugin-transform-spread, babel-plugin-transform-typescript, babel-preset-env
  • #​12115 Mark class prototype as read-only (@​wentout)

🐛 Bug Fix

• babel-plugin-transform-parameters
  • #​14032 Fix: default rest argument array elements as undefined (@​The-x-Theorist)
• babel-plugin-transform-arrow-functions, babel-traverse
  • #​14036 Don't resolve shadowed arguments variables from functions (@​The-x-Theorist)
• babel-parser
  • #​14039 maintain estree string literal shape when cloned (@​JLHwung)
• babel-traverse
  • #​14016 Fix duplicate declaration error on ambient class declarations (@​The-x-Theorist)
• babel-generator
  • #​14014 Support flow function type annotation with no parent (@​krosenberg)
• babel-plugin-transform-react-jsx
  • #​14012 Fix JSX pragma anywhere in comment (@​The-x-Theorist)
• babel-helper-create-class-features-plugin, babel-helper-environment-visitor, babel-helper-member-expression-to-functions, babel-helper-module-transforms, babel-helper-replace-supers, babel-plugin-transform-classes, babel-traverse
  • #​14005 Fix handling of this&co in computed keys in arrows transform (@​nicolo-ribaudo)

💅 Polish

• babel-parser
  • #​13968 Recover from shorthand assign exprs (@​JLHwung)
  • #​13975 fix: update UnexpectedPrivateField error message (@​JLHwung)

📝 Documentation

• babel-compat-data, babel-helper-annotate-as-pure, babel-helper-builder-binary-assignment-operator-visitor, babel-helper-builder-react-jsx, babel-helper-compilation-targets, babel-helper-create-class-features-plugin, babel-helper-create-regexp-features-plugin, babel-helper-define-map, babel-helper-explode-assignable-expression, babel-helper-fixtures, babel-helper-function-name, babel-helper-get-function-arity, babel-helper-hoist-variables, babel-helper-member-expression-to-functions, babel-helper-module-imports, babel-helper-module-transforms, babel-helper-optimise-call-expression, babel-helper-plugin-test-runner, babel-helper-plugin-utils, babel-helper-remap-async-to-generator, babel-helper-replace-supers, babel-helper-simple-access, babel-helper-skip-transparent-expression-wrappers, babel-helper-split-export-declaration, babel-helper-transform-fixture-test-runner, babel-helper-validator-identifier, babel-helper-validator-option, babel-helper-wrap-function, babel-plugin-bugfix-safari-id-destructuring-collision-in-function-expression, babel-plugin-bugfix-v8-spread-parameters-in-optional-chaining, babel-plugin-proposal-async-do-expressions, babel-plugin-proposal-record-and-tuple, babel-plugin-syntax-async-do-expressions, babel-plugin-syntax-module-blocks, babel-plugin-transform-react-jsx-development, babel-plugin-transform-react-pure-annotations, babel-runtime-corejs2, babel-runtime-corejs3, babel-runtime
  • #​14006 Regenerate monorepo READMEs (@​nicolo-ribaudo)

🏠 Internal

• babel-cli, babel-code-frame, babel-core, babel-generator, babel-helper-annotate-as-pure, babel-helper-compilation-targets, babel-helper-create-class-features-plugin, babel-helper-create-regexp-features-plugin, babel-helper-fixtures, babel-helper-module-imports, babel-helper-optimise-call-expression, babel-helper-plugin-test-runner, babel-helper-transform-fixture-test-runner, babel-helper-validator-identifier, babel-helper-validator-option, babel-helpers, babel-highlight, babel-node, babel-parser, babel-plugin-bugfix-safari-id-destructuring-collision-in-function-expression, babel-plugin-bugfix-v8-spread-parameters-in-optional-chaining, babel-plugin-external-helpers, babel-plugin-proposal-async-do-expressions, babel-plugin-proposal-async-generator-functions, babel-plugin-proposal-class-properties, babel-plugin-proposal-class-static-block, babel-plugin-proposal-decorators, babel-plugin-proposal-do-expressions, babel-plugin-proposal-dynamic-import, babel-plugin-proposal-export-default-from, babel-plugin-proposal-export-namespace-from, babel-plugin-proposal-function-bind, babel-plugin-proposal-function-sent, babel-plugin-proposal-json-strings, babel-plugin-proposal-logical-assignment-operators, babel-plugin-proposal-nullish-coalescing-operator, babel-plugin-proposal-numeric-separator, babel-plugin-proposal-object-rest-spread, babel-plugin-proposal-optional-catch-binding, babel-plugin-proposal-optional-chaining, babel-plugin-proposal-partial-application, babel-plugin-proposal-pipeline-operator, babel-plugin-proposal-private-methods, babel-plugin-proposal-private-property-in-object, babel-plugin-proposal-record-and-tuple, babel-plugin-proposal-throw-expressions, babel-plugin-proposal-unicode-property-regex, babel-plugin-syntax-decorators, babel-plugin-syntax-typescript, babel-plugin-transform-arrow-functions, babel-plugin-transform-async-to-generator, babel-plugin-transform-block-scoped-functions, babel-plugin-transform-block-scoping, babel-plugin-transform-classes, babel-plugin-transform-computed-properties, babel-plugin-transform-destructuring, babel-plugin-transform-dotall-regex, babel-plugin-transform-duplicate-keys, babel-plugin-transform-exponentiation-operator, babel-plugin-transform-flow-comments, babel-plugin-transform-flow-strip-types, babel-plugin-transform-for-of, babel-plugin-transform-function-name, babel-plugin-transform-instanceof, babel-plugin-transform-jscript, babel-plugin-transform-member-expression-literals, babel-plugin-transform-modules-amd, babel-plugin-transform-modules-commonjs, babel-plugin-transform-modules-systemjs, babel-plugin-transform-modules-umd, babel-plugin-transform-named-capturing-groups-regex, babel-plugin-transform-new-target, babel-plugin-transform-object-super, babel-plugin-transform-parameters, babel-plugin-transform-property-literals, babel-plugin-transform-property-mutators, babel-plugin-transform-proto-to-assign, babel-plugin-transform-react-constant-elements, babel-plugin-transform-react-display-name, babel-plugin-transform-react-inline-elements, babel-plugin-transform-react-jsx-compat, babel-plugin-transform-react-jsx-development, babel-plugin-transform-react-jsx-self, babel-plugin-transform-react-jsx-source, babel-plugin-transform-react-jsx, babel-plugin-transform-react-pure-annotations, babel-plugin-transform-regenerator, babel-plugin-transform-reserved-words, babel-plugin-transform-runtime, babel-plugin-transform-shorthand-properties, babel-plugin-transform-spread, babel-plugin-transform-sticky-regex, babel-plugin-transform-strict-mode, babel-plugin-transform-template-literals, babel-plugin-transform-typeof-symbol, babel-plugin-transform-typescript, babel-plugin-transform-unicode-escapes, babel-plugin-transform-unicode-regex, babel-preset-env, babel-preset-flow, babel-preset-react, babel-preset-typescript, babel-register, babel-standalone, babel-template, babel-traverse, babel-types
  • #​13966 Run tests in a native Node.js ESM environment (@​nicolo-ribaudo)
• babel-parser
  • #​13982 Extend hasPlugin to accept plugin-configuration array pairs (@​js-choi)
• babel-helpers
  • #​13996 Don't use ESM for required files in @babel/helpers tests (@​nicolo-ribaudo)
• babel-plugin-proposal-object-rest-spread, babel-traverse
  • #​13948 Convert proposal-object-rest-spread to TS (@​JLHwung)
• babel-parser, babel-plugin-bugfix-safari-id-destructuring-collision-in-function-expression, babel-plugin-bugfix-v8-spread-parameters-in-optional-chaining, babel-plugin-proposal-optional-chaining, babel-preset-react, babel-preset-typescript
  • #​13978 Only bundle the release build, and don't import src in tests (@​nicolo-ribaudo)
• Other
  • #​13976 Fail CI when @babel/runtime ESM tests fail (@​nicolo-ribaudo)

🏃‍♀️ Performance

• babel-parser
  • #​13919 Improve template tokenizing (@​JLHwung)

🔬 Output optimization

• babel-helpers, babel-plugin-proposal-async-generator-functions, babel-plugin-transform-runtime, babel-preset-env, babel-runtime-corejs2, babel-runtime
  • #​13837 minify helpers-generated.ts (@​lightmare)

typescript-eslint/typescript-eslint

v5.7.0

Compare Source

Features

• eslint-plugin: [consistent-type-exports] support TS4.5 inline export specifiers (#​4236) (be4d976)
• eslint-plugin: [consistent-type-imports] support TS4.5 inline import specifiers (#​4237) (f61af7c)
• eslint-plugin: [no-shadow] support TS4.5 inline import specifiers (#​4239) (96b7e8e)

evanw/esbuild

v0.14.5

Compare Source

• Fix an issue with the publishing script

  This release fixes a missing dependency issue in the publishing script where it was previously possible for the published binary executable to have an incorrect version number.

v0.14.4

Compare Source

• Adjust esbuild's handling of default exports and the __esModule marker (#​532, #​1591, #​1719)

  This change requires some background for context. Here's the history to the best of my understanding:

  When the ECMAScript module import/export syntax was being developed, the CommonJS module format (used in Node.js) was already widely in use. Because of this the export name called default was given special a syntax. Instead of writing import { default as foo } from 'bar' you can just write import foo from 'bar'. The idea was that when ECMAScript modules (a.k.a. ES modules) were introduced, you could import existing CommonJS modules using the new import syntax for compatibility. Since CommonJS module exports are dynamic while ES module exports are static, it's not generally possible to determine a CommonJS module's export names at module instantiation time since the code hasn't been evaluated yet. So the value of module.exports is just exported as the default export and the special default import syntax gives you easy access to module.exports (i.e. const foo = require('bar') is the same as import foo from 'bar').

  However, it took a while for ES module syntax to be supported natively by JavaScript runtimes, and people still wanted to start using ES module syntax in the meantime. The Babel JavaScript compiler let you do this. You could transform each ES module file into a CommonJS module file that behaved the same. However, this transformation has a problem: emulating the import syntax accurately as described above means that export default 0 and import foo from 'bar' will no longer line up when transformed to CommonJS. The code export default 0 turns into module.exports.default = 0 and the code import foo from 'bar' turns into const foo = require('bar'), meaning foo is 0 before the transformation but foo is { default: 0 } after the transformation.

  To fix this, Babel sets the property __esModule to true as a signal to itself when it converts an ES module to a CommonJS module. Then, when importing a default export, it can know to use the value of module.exports.default instead of module.exports to make sure the behavior of the CommonJS modules correctly matches the behavior of the original ES modules. This fix has been widely adopted across the ecosystem and has made it into other tools such as TypeScript and even esbuild.

  However, when Node.js finally released their ES module implementation, they went with the original implementation where the default export is always module.exports, which broke compatibility with the existing ecosystem of ES modules that had been cross-compiled into CommonJS modules by Babel. You now have to either add or remove an additional .default property depending on whether your code needs to run in a Node environment or in a Babel environment, which created an interoperability headache. In addition, JavaScript tools such as esbuild now need to guess whether you want Node-style or Babel-style default imports. There's no way for a tool to know with certainty which one a given file is expecting and if your tool guesses wrong, your code will break.

  This release changes esbuild's heuristics around default exports and the __esModule marker to attempt to improve compatibility with Webpack and Node, which is what most packages are tuned for. The behavior changes are as follows:

  Old behavior:

  • If an import statement is used to load a CommonJS file and a) module.exports is an object, b) module.exports.__esModule is truthy, and c) the property default exists in module.exports, then esbuild would set the default export to module.exports.default (like Babel). Otherwise the default export was set to module.exports (like Node).

  • If a require call is used to load an ES module file, the returned module namespace object had the __esModule property set to true. This behaved as if the ES module had been converted to CommonJS via a Babel-compatible transformation.

  • The __esModule marker could inconsistently appear on module namespace objects (i.e. import * as) when writing pure ESM code. Specifically, if a module namespace object was materialized then the __esModule marker was present, but if it was optimized away then the __esModule marker was absent.

  • It was not allowed to create an ES module export named __esModule. This avoided generating code that might break due to the inconsistency mentioned above, and also avoided issues with duplicate definitions of __esModule.

  New behavior:

  • If an import statement is used to load a CommonJS file and a) module.exports is an object, b) module.exports.__esModule is truthy, and c) the file name does not end in either .mjs or .mts and the package.json file does not contain "type": "module", then esbuild will set the default export to module.exports.default (like Babel). Otherwise the default export is set to module.exports (like Node).

    Note that this means the default export may now be undefined in situations where it previously wasn't undefined. This matches Webpack's behavior so it should hopefully be more compatible.

    Also note that this means import behavior now depends on the file extension and on the contents of package.json. This also matches Webpack's behavior to hopefully improve compatibility.

  • If a require call is used to load an ES module file, the returned module namespace object has the __esModule property set to true. This behaves as if the ES module had been converted to CommonJS via a Babel-compatible transformation.

  • If an import statement or import() expression is used to load an ES module, the __esModule marker should now never be present on the module namespace object. This frees up the __esModule export name for use with ES modules.

  • It's now allowed to use __esModule as a normal export name in an ES module. This property will be accessible to other ES modules but will not be accessible to code that loads the ES module using require, where they will observe the property set to true instead.

---

Configuration

📅 Schedule: "after 10pm every weekday,before 4am every weekday,every weekend" in timezone America/Tijuana.

🚦 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 WhiteSource Renovate. View repository job log here.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}