fix(deps): lock file maintenance all non-major

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	Age	Confidence
		lockFileMaintenance	All locks refreshed
@eslint/js (source)	devDependencies	minor	9.29.0 -> 9.31.0
@types/node (source)	devDependencies	minor	22.15.32 -> 22.16.5
@yao-pkg/pkg	devDependencies	minor	6.5.1 -> 6.6.0
dotenv	dependencies	minor	16.5.0 -> 16.6.1
esbuild	devDependencies	patch	0.25.5 -> 0.25.8
eslint (source)	devDependencies	minor	9.29.0 -> 9.31.0
sonarsource/sonarqube-scan-action	action	minor	v5.2.0 -> v5.3.0
typescript-eslint (source)	devDependencies	minor	8.34.1 -> 8.38.0

🔧 This Pull Request updates lock files to use the latest dependency versions.

---

Release Notes

eslint/eslint (@​eslint/js)

v9.31.0

Compare Source

v9.30.1

Compare Source

v9.30.0

Compare Source

yao-pkg/pkg (@​yao-pkg/pkg)

v6.6.0

Compare Source

Features

• pkg-fetch@3.5.24 with Node.js versions 20.19.4 and 22.17.1 (6a04030)

Documentation

• add guidance on unsupported architectures to README.md (#​160) (c22e442)

motdotla/dotenv (dotenv)

v16.6.1

Compare Source

Changed

• Default quiet to true – hiding the runtime log message (#​874)
• NOTICE: 17.0.0 will be released with quiet defaulting to false. Use config({ quiet: true }) to suppress.
• And check out the new dotenvx. As coding workflows evolve and agents increasingly handle secrets, encrypted .env files offer a much safer way to deploy both agents and code together with secure secrets. Simply switch require('dotenv').config() for require('@​dotenvx/dotenvx').config().

v16.6.0

Compare Source

Added

• Default log helpful message [dotenv@16.6.0] injecting env (1) from .env (#​870)
• Use { quiet: true } to suppress
• Aligns dotenv more closely with dotenvx.

evanw/esbuild (esbuild)

v0.25.8

Compare Source

• Fix another TypeScript parsing edge case (#​4248)

  This fixes a regression with a change in the previous release that tries to more accurately parse TypeScript arrow functions inside the ?: operator. The regression specifically involves parsing an arrow function containing a #private identifier inside the middle of a ?: ternary operator inside a class body. This was fixed by propagating private identifier state into the parser clone used to speculatively parse the arrow function body. Here is an example of some affected code:

  class CachedDict {
    #has = (a: string) => dict.has(a);
    has = window
      ? (word: string): boolean => this.#has(word)
      : this.#has;
  }

• Fix a regression with the parsing of source phase imports

  The change in the previous release to parse source phase imports failed to properly handle the following cases:

  import source from 'bar'
  import source from from 'bar'
  import source type foo from 'bar'

  Parsing for these cases should now be fixed. The first case was incorrectly treated as a syntax error because esbuild was expecting the second case. And the last case was previously allowed but is now forbidden. TypeScript hasn't added this feature yet so it remains to be seen whether the last case will be allowed, but it's safer to disallow it for now. At least Babel doesn't allow the last case when parsing TypeScript, and Babel was involved with the source phase import specification.

v0.25.7

Compare Source

• Parse and print JavaScript imports with an explicit phase (#​4238)

  This release adds basic syntax support for the defer and source import phases in JavaScript:

  • defer

    This is a stage 3 proposal for an upcoming JavaScript feature that will provide one way to eagerly load but lazily initialize imported modules. The imported module is automatically initialized on first use. Support for this syntax will also be part of the upcoming release of TypeScript 5.9. The syntax looks like this:

    import defer * as foo from "<specifier>";
    const bar = await import.defer("<specifier>");

    Note that this feature deliberately cannot be used with the syntax import defer foo from "<specifier>" or import defer { foo } from "<specifier>".

  • source

    This is a stage 3 proposal for an upcoming JavaScript feature that will provide another way to eagerly load but lazily initialize imported modules. The imported module is returned in an uninitialized state. Support for this syntax may or may not be a part of TypeScript 5.9 (see this issue for details). The syntax looks like this:

    import source foo from "<specifier>";
    const bar = await import.source("<specifier>");

    Note that this feature deliberately cannot be used with the syntax import defer * as foo from "<specifier>" or import defer { foo } from "<specifier>".

  This change only adds support for this syntax. These imports cannot currently be bundled by esbuild. To use these new features with esbuild's bundler, the imported paths must be external to the bundle and the output format must be set to esm.

• Support optionally emitting absolute paths instead of relative paths (#​338, #​2082, #​3023)

  This release introduces the --abs-paths= feature which takes a comma-separated list of situations where esbuild should use absolute paths instead of relative paths. There are currently three supported situations: code (comments and string literals), log (log message text and location info), and metafile (the JSON build metadata).

  Using absolute paths instead of relative paths is not the default behavior because it means that the build results are no longer machine-independent (which means builds are no longer reproducible). Absolute paths can be useful when used with certain terminal emulators that allow you to click on absolute paths in the terminal text and/or when esbuild is being automatically invoked from several different directories within the same script.

• Fix a TypeScript parsing edge case (#​4241)

  This release fixes an edge case with parsing an arrow function in TypeScript with a return type that's in the middle of a ?: ternary operator. For example:

  x = a ? (b) : c => d;
  y = a ? (b) : c => d : e;

  The : token in the value assigned to x pairs with the ? token, so it's not the start of a return type annotation. However, the first : token in the value assigned to y is the start of a return type annotation because after parsing the arrow function body, it turns out there's another : token that can be used to pair with the ? token. This case is notable as it's the first TypeScript edge case that esbuild has needed a backtracking parser to parse. It has been addressed by a quick hack (cloning the whole parser) as it's a rare edge case and esbuild doesn't otherwise need a backtracking parser. Hopefully this is sufficient and doesn't cause any issues.

• Inline small constant strings when minifying

  Previously esbuild's minifier didn't inline string constants because strings can be arbitrarily long, and this isn't necessarily a size win if the string is used more than once. Starting with this release, esbuild will now inline string constants when the length of the string is three code units or less. For example:

  // Original code
  const foo = 'foo'
  console.log({ [foo]: true })
  
  // Old output (with --minify --bundle --format=esm)
  var o="foo";console.log({[o]:!0});
  
  // New output (with --minify --bundle --format=esm)
  console.log({foo:!0});

  Note that esbuild's constant inlining only happens in very restrictive scenarios to avoid issues with TDZ handling. This change doesn't change when esbuild's constant inlining happens. It only expands the scope of it to include certain string literals in addition to numeric and boolean literals.

v0.25.6

Compare Source

• Fix a memory leak when cancel() is used on a build context (#​4231)

  Calling rebuild() followed by cancel() in rapid succession could previously leak memory. The bundler uses a producer/consumer model internally, and the resource leak was caused by the consumer being termianted while there were still remaining unreceived results from a producer. To avoid the leak, the consumer now waits for all producers to finish before terminating.

• Support empty :is() and :where() syntax in CSS (#​4232)

  Previously using these selectors with esbuild would generate a warning. That warning has been removed in this release for these cases.

• Improve tree-shaking of try statements in dead code (#​4224)

  With this release, esbuild will now remove certain try statements if esbuild considers them to be within dead code (i.e. code that is known to not ever be evaluated). For example:

  // Original code
  return 'foo'
  try { return 'bar' } catch {}
  
  // Old output (with --minify)
  return"foo";try{return"bar"}catch{}
  
  // New output (with --minify)
  return"foo";

• Consider negated bigints to have no side effects

  While esbuild currently considers 1, -1, and 1n to all have no side effects, it didn't previously consider -1n to have no side effects. This is because esbuild does constant folding with numbers but not bigints. However, it meant that unused negative bigint constants were not tree-shaken. With this release, esbuild will now consider these expressions to also be side-effect free:

  // Original code
  let a = 1, b = -1, c = 1n, d = -1n
  
  // Old output (with --bundle --minify)
  (()=>{var n=-1n;})();
  
  // New output (with --bundle --minify)
  (()=>{})();

• Support a configurable delay in watch mode before rebuilding (#​3476, #​4178)

  The watch() API now takes a delay option that lets you add a delay (in milliseconds) before rebuilding when a change is detected in watch mode. If you use a tool that regenerates multiple source files very slowly, this should make it more likely that esbuild's watch mode won't generate a broken intermediate build before the successful final build. This option is also available via the CLI using the --watch-delay= flag.

  This should also help avoid confusion about the watch() API's options argument. It was previously empty to allow for future API expansion, which caused some people to think that the documentation was missing. It's no longer empty now that the watch() API has an option.

• Allow mixed array for entryPoints API option (#​4223)

  The TypeScript type definitions now allow you to pass a mixed array of both string literals and object literals to the entryPoints API option, such as ['foo.js', { out: 'lib', in: 'bar.js' }]. This was always possible to do in JavaScript but the TypeScript type definitions were previously too restrictive.

• Update Go from 1.23.8 to 1.23.10 (#​4204, #​4207)

  This should have no effect on existing code as this version change does not change Go's operating system support. It may remove certain false positive reports (specifically CVE-2025-4673 and CVE-2025-22874) from vulnerability scanners that only detect which version of the Go compiler esbuild uses.

• Experimental support for esbuild on OpenHarmony (#​4212)

  With this release, esbuild now publishes the @esbuild/openharmony-arm64 npm package for OpenHarmony. It contains a WebAssembly binary instead of a native binary because Go doesn't currently support OpenHarmony. Node does support it, however, so in theory esbuild should now work on OpenHarmony through WebAssembly.

  This change was contributed by @​hqzing.

eslint/eslint (eslint)

v9.31.0

Compare Source

v9.30.1

Compare Source

v9.30.0

Compare Source

sonarsource/sonarqube-scan-action (sonarsource/sonarqube-scan-action)

v5.3.0

Compare Source

What's Changed

• SQSCANGHA-83 Avoid unbound variable error on parameter expansion by @​aleksandra-bozhinoska-sonarsource in https://github.com/SonarSource/sonarqube-scan-action/pull/192
• SQSCANGHA-97 Use /usr/bin/env for shebang by @​eliandoran in https://github.com/SonarSource/sonarqube-scan-action/pull/193
• SQSCANGHA-98 Update SonarScanner CLI to 7.2.0.5079 by @​github-actions[bot] inhttps://github.com/SonarSource/sonarqube-scan-action/pull/1966

New Contributors

• @​eliandoran made their first contribution in https://github.com/SonarSource/sonarqube-scan-action/pull/193

Full Changelog: SonarSource/sonarqube-scan-action@v5.2.0...v5.3.0

typescript-eslint/typescript-eslint (typescript-eslint)

v8.38.0

Compare Source

🩹 Fixes

• typescript-eslint: error on nested extends in tseslint.config() (#​11361)
• typescript-eslint: infer tsconfigRootDir with v8 API (#​11412)

❤️ Thank You

• Kirk Waiblinger @​kirkwaiblinger

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

v8.37.0

Compare Source

🚀 Features

• typescript-estree: infer tsconfigRootDir from call stack (#​11370)

❤️ Thank You

• Josh Goldberg ✨

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

v8.36.0

Compare Source

🚀 Features

• typescript-eslint: support basePath in tseslint.config() (#​11357)

❤️ Thank You

• Kirk Waiblinger @​kirkwaiblinger

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

v8.35.1

Compare Source

This was a version bump only for typescript-eslint to align it with other projects, there were no code changes.

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

v8.35.0

Compare Source

This was a version bump only for typescript-eslint to align it with other projects, there were no code changes.

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

---

Configuration

📅 Schedule: Branch creation - Between 12:00 AM and 03:59 AM, only on Monday ( * 0-3 * * 1 ) (UTC), 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, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud