npm: bump the development-dependencies group with 3 updates

[dependabot]

Bumps the development-dependencies group with 3 updates: @typescript-eslint/eslint-plugin, @typescript-eslint/parser and esbuild.

Updates @typescript-eslint/eslint-plugin from 6.15.0 to 6.16.0

Release notes

Sourced from @​typescript-eslint/eslint-plugin's releases.

v6.16.0

6.16.0 (2023-12-25)

Bug Fixes

• eslint-plugin: [unbound-method] exempt all non-Promise built-in statics (#8096) (3182959)

Features

• eslint-plugin: deprecate formatting rules (#8073) (04dea84)
• typescript-estree: add allowDefaultProjectForFiles project service allowlist option (#7752) (7ddadda)

You can read about our versioning strategy and releases on our website.

Changelog

Sourced from @​typescript-eslint/eslint-plugin's changelog.

6.16.0 (2023-12-25)

Bug Fixes

• eslint-plugin: [unbound-method] exempt all non-Promise built-in statics (#8096) (3182959)

Features

• eslint-plugin: deprecate formatting (meta.type: layout) rules (#8073) (04dea84)
• eslint-plugin: deprecate no-extra-semi in favor of ESLint Stylistic equivalent (#8123) (9368bf3)

You can read about our versioning strategy and releases on our website.

Commits

• 7246e56 chore: publish v6.16.0
• 3182959 fix(eslint-plugin): [unbound-method] exempt all non-Promise built-in statics ...
• 3031117 docs(eslint-plugin): enforce a heading for each rule option (#8015)
• b3f87fc docs(eslint-plugin): add Deprecating Formatting Rules blog post (#8117)
• 9368bf3 feat(eslint-plugin): deprecate no-extra-semi in favor of ESLint Stylistic equ...
• f6f6a57 docs: add tombstone file for no-parameter-properties and suggested replacemen...
• 04dea84 feat(eslint-plugin): deprecate formatting (meta.type: layout) rules (#8073)
• b1c92bb chore(website): auto-generate type checked rule notice in rule docs (#7951)
• 26ba8ea docs: add more rationale for no-for-in-array (#8082)
• eff7da1 docs: fix example for no-shadow (#8080)
• See full diff in compare view

Updates @typescript-eslint/parser from 6.15.0 to 6.16.0

Release notes

Sourced from @​typescript-eslint/parser's releases.

v6.16.0

6.16.0 (2023-12-25)

Bug Fixes

• eslint-plugin: [unbound-method] exempt all non-Promise built-in statics (#8096) (3182959)

Features

• eslint-plugin: deprecate formatting rules (#8073) (04dea84)
• typescript-estree: add allowDefaultProjectForFiles project service allowlist option (#7752) (7ddadda)

You can read about our versioning strategy and releases on our website.

Changelog

Sourced from @​typescript-eslint/parser's changelog.

6.16.0 (2023-12-25)

Note: Version bump only for package @​typescript-eslint/parser

You can read about our versioning strategy and releases on our website.

Commits

• 7246e56 chore: publish v6.16.0
• See full diff in compare view

Updates esbuild from 0.19.9 to 0.19.10

Release notes

Sourced from esbuild's releases.

v0.19.10

• Fix glob imports in TypeScript files (#3319)

  This release fixes a problem where bundling a TypeScript file containing a glob import could emit a call to a helper function that doesn't exist. The problem happened because esbuild's TypeScript transformation removes unused imports (which is required for correctness, as they may be type-only imports) and esbuild's glob import transformation wasn't correctly marking the imported helper function as used. This wasn't caught earlier because most of esbuild's glob import tests were written in JavaScript, not in TypeScript.

• Fix require() glob imports with bundling disabled (#3546)

  Previously require() calls containing glob imports were incorrectly transformed when bundling was disabled. All glob imports should only be transformed when bundling is enabled. This bug has been fixed.

• Fix a panic when transforming optional chaining with define (#3551, #3554)

  This release fixes a case where esbuild could crash with a panic, which was triggered by using define to replace an expression containing an optional chain. Here is an example:

  // Original code
  console.log(process?.env.SHELL)
  // Old output (with --define:process.env={})
  /* panic: Internal error (while parsing "<stdin>") */
  // New output (with --define:process.env={})
  var define_process_env_default = {};
  console.log(define_process_env_default.SHELL);

  This fix was contributed by @​hi-ogawa.

• Work around a bug in node's CommonJS export name detector (#3544)

  The export names of a CommonJS module are dynamically-determined at run time because CommonJS exports are properties on a mutable object. But the export names of an ES module are statically-determined at module instantiation time by using import and export syntax and cannot be changed at run time.

  When you import a CommonJS module into an ES module in node, node scans over the source code to attempt to detect the set of export names that the CommonJS module will end up using. That statically-determined set of names is used as the set of names that the ES module is allowed to import at module instantiation time. However, this scan appears to have bugs (or at least, can cause false positives) because it doesn't appear to do any scope analysis. Node will incorrectly consider the module to export something even if the assignment is done to a local variable instead of to the module-level exports object. For example:

  // confuseNode.js
  exports.confuseNode = function(exports) {
    // If this local is called "exports", node incorrectly
    // thinks this file has an export called "notAnExport".
    exports.notAnExport = function() {
    };
  };

  You can see that node incorrectly thinks the file confuseNode.js has an export called notAnExport when that file is loaded in an ES module context:

  $ node -e 'import("./confuseNode.js").then(console.log)'
  [Module: null prototype] {
    confuseNode: [Function (anonymous)],
    default: { confuseNode: [Function (anonymous)] },

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.19.10

• Fix glob imports in TypeScript files (#3319)

  This release fixes a problem where bundling a TypeScript file containing a glob import could emit a call to a helper function that doesn't exist. The problem happened because esbuild's TypeScript transformation removes unused imports (which is required for correctness, as they may be type-only imports) and esbuild's glob import transformation wasn't correctly marking the imported helper function as used. This wasn't caught earlier because most of esbuild's glob import tests were written in JavaScript, not in TypeScript.

• Fix require() glob imports with bundling disabled (#3546)

  Previously require() calls containing glob imports were incorrectly transformed when bundling was disabled. All glob imports should only be transformed when bundling is enabled. This bug has been fixed.

• Fix a panic when transforming optional chaining with define (#3551, #3554)

  This release fixes a case where esbuild could crash with a panic, which was triggered by using define to replace an expression containing an optional chain. Here is an example:

  // Original code
  console.log(process?.env.SHELL)
  // Old output (with --define:process.env={})
  /* panic: Internal error (while parsing "<stdin>") */
  // New output (with --define:process.env={})
  var define_process_env_default = {};
  console.log(define_process_env_default.SHELL);

  This fix was contributed by @​hi-ogawa.

• Work around a bug in node's CommonJS export name detector (#3544)

  The export names of a CommonJS module are dynamically-determined at run time because CommonJS exports are properties on a mutable object. But the export names of an ES module are statically-determined at module instantiation time by using import and export syntax and cannot be changed at run time.

  When you import a CommonJS module into an ES module in node, node scans over the source code to attempt to detect the set of export names that the CommonJS module will end up using. That statically-determined set of names is used as the set of names that the ES module is allowed to import at module instantiation time. However, this scan appears to have bugs (or at least, can cause false positives) because it doesn't appear to do any scope analysis. Node will incorrectly consider the module to export something even if the assignment is done to a local variable instead of to the module-level exports object. For example:

  // confuseNode.js
  exports.confuseNode = function(exports) {
    // If this local is called "exports", node incorrectly
    // thinks this file has an export called "notAnExport".
    exports.notAnExport = function() {
    };
  };

  You can see that node incorrectly thinks the file confuseNode.js has an export called notAnExport when that file is loaded in an ES module context:

  $ node -e 'import("./confuseNode.js").then(console.log)'
  [Module: null prototype] {
    confuseNode: [Function (anonymous)],

... (truncated)

Commits

• 55e1127 publish 0.19.10 to npm
• d968af2 fix #3511: @__NO_SIDE_EFFECTS__ with templates
• 00c4ebe fix #3546: don't transform require glob imports
• e1b7050 fix #3319: missing symbol usage in glob transform
• 461ca73 add the @esbuild/aix-ppc64 package for ibm aix (#3550)
• 190ca99 truncate a long url in a comment
• 6c41900 add Safari compat data for arbitrary module namespace names (#3520)
• f38cbe6 fix #3552: calling stop() now clears go timeouts
• 7a225ff make a few code edits from some random github bot
• aa46b2c fix some build script comments
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions