ts-jest 29.4.9 → 29.4.10

package/.ts-jest-digest

@@ -1 +1 @@
-58edfe49f3f9192570efa8fa26d9cbc324d1324e
+19e702f0a49983ce6d92683fb1199ea2acf8e36a

package/CHANGELOG.md

@@ -1,3 +1,34 @@
+## [29.4.10](https://github.com/kulshekhar/ts-jest/compare/v29.4.9...v29.4.10) (2026-05-18)
+
+
+### Bug Fixes
+
+* pass `resolutionMode` to `ts.resolveModuleName` for hybrid module support ([b557a85](https://github.com/kulshekhar/ts-jest/commit/b557a85f85c3fd34523ec3a15293afbdc9dea83c))
+* rebuild `Program` when consecutive compiles need different module kinds ([a82a2b3](https://github.com/kulshekhar/ts-jest/commit/a82a2b32c4987a5249fd5284283117dd2fa3be47)), closes [#4774](https://github.com/kulshekhar/ts-jest/issues/4774)
+* respect tsconfig `moduleResolution` instead of forcing `Node10` ([1bffffc](https://github.com/kulshekhar/ts-jest/commit/1bffffc667557c173ae0c1f93dd436920775dac4))
+* **transformer:** transpile `mjs` files from `node_modules` for CJS mode ([96d025d](https://github.com/kulshekhar/ts-jest/commit/96d025dd912ea2bceb18b67d2d509ada7a756d9d))
+* **transformer:** use a consistent comparator in hoist-jest sortStatements ([8a8fd2f](https://github.com/kulshekhar/ts-jest/commit/8a8fd2fb8446655bba18367db9306a1089490e62))
+
+
+
+## [29.4.9](https://github.com/kulshekhar/ts-jest/compare/v29.4.8...v29.4.9) (2026-04-01)
+
+
+### Bug Fixes
+
+* use correct registry for npm OIDC trusted publishing ([f8a9cc9](https://github.com/kulshekhar/ts-jest/commit/f8a9cc9892))
+
+
+
+## [29.4.8](https://github.com/kulshekhar/ts-jest/compare/v29.4.7...v29.4.8) (2026-04-01)
+
+
+### Bug Fixes
+
+* wrong published assets
+
+
+
 ## [29.4.7](https://github.com/kulshekhar/ts-jest/compare/v29.4.6...v29.4.7) (2026-04-01)
 
 
@@ -5,6 +36,8 @@
 
 * support TypeScript v6 ([eda517d](https://github.com/kulshekhar/ts-jest/commit/eda517d226389317d99572887d3c1aa93c81be87))
 
+
+
 ## [29.4.6](https://github.com/kulshekhar/ts-jest/compare/v29.4.5...v29.4.6) (2025-12-01)
 
 

package/dist/legacy/compiler/ts-compiler.d.ts

@@ -20,7 +20,109 @@ export declare class TsCompiler implements TsCompilerInstance {
     program: Program | undefined;
     constructor(configSet: ConfigSet, runtimeCacheFS: StringMap);
     getResolvedModules(fileContent: string, fileName: string, runtimeCacheFS: StringMap): string[];
+    /**
+     * Apply ts-jest's runtime fixups on top of the user's compiler options before
+     * handing them to the language service or transpiler.
+     *
+     * Two compiler-options now flow through dedicated helpers so the produced
+     * options are always a TypeScript-valid combination:
+     *
+     *   - `moduleResolution` is delegated to `resolveCompatibleModuleResolution`,
+     *     which preserves the user's value when it is valid alongside the
+     *     `module` ts-jest forces at runtime (CommonJS on the CJS path, or
+     *     ESNext / the user's original `module` on the ESM path) and otherwise
+     *     substitutes a TypeScript-valid alternative. When the user has not set
+     *     a value the historical Node10 default is kept, so unchanged tsconfigs
+     *     see the exact same resolved options as before.
+     *
+     *   - `customConditions` is delegated to `preserveCustomConditionsIfCompatible`,
+     *     which keeps the user's value only when the resolved
+     *     `moduleResolution` supports it (`Bundler` / `Node16` / `NodeNext`)
+     *     and clears it otherwise. The pre-#4198 code unconditionally cleared
+     *     this option because the hardcoded `Node10` override always made it
+     *     incompatible; that is no longer true.
+     *
+     * @see https://github.com/kulshekhar/ts-jest/issues/4198
+     */
     private fixupCompilerOptionsForModuleKind;
+    /**
+     * Pick a `moduleResolution` value that is valid alongside the `module` ts-jest
+     * forces at runtime. Closes #4198: previously this was hardcoded to Node10 and
+     * silently overrode whatever the user set in tsconfig, even when the user value
+     * would have been valid (e.g. Bundler with module: ESNext, Classic with CommonJS).
+     *
+     * Substitution rules — each tied to a specific TypeScript diagnostic that the
+     * resulting combination would otherwise raise. The "Bundler-compatible" set is
+     * the one defined by `isBundlerCompatibleModuleKind` (ES2015 / ES2020 / ES2022
+     * / ESNext / Preserve); everything else (CommonJS / AMD / UMD / System / None)
+     * is treated as Bundler-incompatible across the full supported TS range.
+     *
+     *   - Node16 / NodeNext require `module: Node16` or `module: NodeNext` (TS5110).
+     *     ts-jest never emits those module kinds, so these user-supplied values are
+     *     substituted: to Bundler when the forced module is in the
+     *     Bundler-compatible set, or to Node10 otherwise. (Pairing Bundler with a
+     *     non-ES module raises TS5095, and Node10 is the only kind that has been
+     *     valid with non-ES modules across every TypeScript version ts-jest
+     *     supports.)
+     *
+     *   - User-supplied Bundler with a non-Bundler-compatible forced module is
+     *     also TS5095 on the supported TS range — substitute Node10. (TypeScript
+     *     6 relaxed this for `module: CommonJS` specifically; that relaxation is
+     *     deliberately not encoded here so behavior stays consistent across the
+     *     full peerDependency range. See `isBundlerCompatibleModuleKind` for the
+     *     follow-up pointer.)
+     *
+     *   - Anything else (Node10 / Classic / unset) passes through or falls back
+     *     to Node10. These pairings are valid with every forced module kind.
+     *
+     * Compatibility: `ModuleResolutionKind.Bundler` was introduced in
+     * TypeScript 5.0. ts-jest declares `peerDependencies: { typescript: ">=4.3 <7" }`,
+     * so the Bundler member is `undefined` at runtime on TypeScript 4.3 - 4.9.
+     * The Node16/NodeNext substitution falls back to Node10 in that case
+     * (`bundlerResolution` below) to keep the function deterministic across the
+     * full supported range. Users on TypeScript < 5 can never have set Bundler in
+     * tsconfig (the parser rejects it), so the user-supplied-Bundler branch is
+     * unreachable there and needs no separate guard.
+     */
+    private resolveCompatibleModuleResolution;
+    /**
+     * TypeScript pairs `moduleResolution: bundler` only with ES-module module
+     * kinds (`ES2015` / `ES2020` / `ES2022` / `ESNext`) or `Preserve` (added in
+     * TypeScript 5.4). Pairing `bundler` with `CommonJS`, `AMD`, `UMD`, `System`,
+     * or `None` raises TS5095. Used by `resolveCompatibleModuleResolution` to
+     * gate the `Node16` / `NodeNext` → `Bundler` substitution and the
+     * user-supplied-`Bundler` pass-through, so neither path emits an invalid
+     * pair when the user has selected a non-ES `module`.
+     *
+     * Note: TypeScript 6.0 relaxed this restriction for `module: CommonJS`
+     * specifically (`CommonJS` + `Bundler` is now a valid pair on TS ≥ 6); the
+     * other non-ES module kinds (`AMD` / `UMD` / `System` / `None`) remain
+     * Bundler-incompatible on every TypeScript version. The TS 6 relaxation is
+     * intentionally not encoded here to keep behavior consistent across the full
+     * peerDependency range (`>=4.3 <7`); honoring it can ride in as a follow-up
+     * once the TS 6 baseline lands.
+     *
+     * @see https://www.typescriptlang.org/tsconfig/#moduleResolution
+     */
+    private isBundlerCompatibleModuleKind;
+    /**
+     * Pass `customConditions` through unchanged when the resolved
+     * `moduleResolution` is one of the kinds that supports it (`Bundler`,
+     * `Node16`, `NodeNext`); strip it otherwise. TypeScript raises TS5098
+     * when `customConditions` is paired with any other resolution kind
+     * (verified empirically against TypeScript 5.9.3 with `tsc -p`).
+     *
+     * Before #4198 the surrounding `fixupCompilerOptionsForModuleKind`
+     * unconditionally cleared `customConditions` because the hardcoded
+     * `Node10` override always made it incompatible. After #4198 the
+     * resolved `moduleResolution` can be `Bundler` (e.g. when the user
+     * has `Node16`/`NodeNext` paired with an ES-family `module`), so we
+     * need to preserve the user's `customConditions` in that case rather
+     * than silently dropping it.
+     *
+     * @see https://www.typescriptlang.org/tsconfig/#customConditions
+     */
+    private preserveCustomConditionsIfCompatible;
     getCompiledOutput(fileContent: string, fileName: string, options: TsJestCompileOptions): CompiledOutput;
     protected _transpileOutput(fileContent: string, fileName: string): TranspileOutput;
     protected _makeTransformers(customTransformers: TsJestAstTransformer): CustomTransformers;

package/dist/legacy/compiler/ts-compiler.js

@@ -49,6 +49,10 @@ class TsCompiler {
      * @internal
      */
     _projectVersion = 1;
+    /**
+     * @internal
+     */
+    _previousCompiledModuleKind;
     /**
      * @internal
      */
@@ -107,17 +111,38 @@ class TsCompiler {
         });
         return importedModulePaths;
     }
+    /**
+     * Apply ts-jest's runtime fixups on top of the user's compiler options before
+     * handing them to the language service or transpiler.
+     *
+     * Two compiler-options now flow through dedicated helpers so the produced
+     * options are always a TypeScript-valid combination:
+     *
+     *   - `moduleResolution` is delegated to `resolveCompatibleModuleResolution`,
+     *     which preserves the user's value when it is valid alongside the
+     *     `module` ts-jest forces at runtime (CommonJS on the CJS path, or
+     *     ESNext / the user's original `module` on the ESM path) and otherwise
+     *     substitutes a TypeScript-valid alternative. When the user has not set
+     *     a value the historical Node10 default is kept, so unchanged tsconfigs
+     *     see the exact same resolved options as before.
+     *
+     *   - `customConditions` is delegated to `preserveCustomConditionsIfCompatible`,
+     *     which keeps the user's value only when the resolved
+     *     `moduleResolution` supports it (`Bundler` / `Node16` / `NodeNext`)
+     *     and clears it otherwise. The pre-#4198 code unconditionally cleared
+     *     this option because the hardcoded `Node10` override always made it
+     *     incompatible; that is no longer true.
+     *
+     * @see https://github.com/kulshekhar/ts-jest/issues/4198
+     */
     fixupCompilerOptionsForModuleKind(compilerOptions, isEsm) {
-        const moduleResolution = this._ts.ModuleResolutionKind.Node10 ?? this._ts.ModuleResolutionKind.NodeJs;
         if (!isEsm) {
+            const moduleResolution = this.resolveCompatibleModuleResolution(this._ts.ModuleKind.CommonJS, compilerOptions.moduleResolution);
             return {
                 ...compilerOptions,
                 module: this._ts.ModuleKind.CommonJS,
                 moduleResolution,
-                /**
-                 * This option is only supported in `Node16`/`NodeNext` and `Bundler` module, see https://www.typescriptlang.org/tsconfig/#customConditions
-                 */
-                customConditions: undefined,
+                customConditions: this.preserveCustomConditionsIfCompatible(moduleResolution, compilerOptions.customConditions),
             };
         }
         let moduleKind = compilerOptions.module ?? this._ts.ModuleKind.ESNext;
@@ -126,22 +151,134 @@ class TsCompiler {
             esModuleInterop = true;
             moduleKind = this._ts.ModuleKind.ESNext;
         }
+        const moduleResolution = this.resolveCompatibleModuleResolution(moduleKind, compilerOptions.moduleResolution);
         return {
             ...compilerOptions,
             module: moduleKind,
             esModuleInterop,
             moduleResolution,
-            /**
-             * This option is only supported in `Node16`/`NodeNext` and `Bundler` module, see https://www.typescriptlang.org/tsconfig/#customConditions
-             */
-            customConditions: undefined,
+            customConditions: this.preserveCustomConditionsIfCompatible(moduleResolution, compilerOptions.customConditions),
         };
     }
+    /**
+     * Pick a `moduleResolution` value that is valid alongside the `module` ts-jest
+     * forces at runtime. Closes #4198: previously this was hardcoded to Node10 and
+     * silently overrode whatever the user set in tsconfig, even when the user value
+     * would have been valid (e.g. Bundler with module: ESNext, Classic with CommonJS).
+     *
+     * Substitution rules — each tied to a specific TypeScript diagnostic that the
+     * resulting combination would otherwise raise. The "Bundler-compatible" set is
+     * the one defined by `isBundlerCompatibleModuleKind` (ES2015 / ES2020 / ES2022
+     * / ESNext / Preserve); everything else (CommonJS / AMD / UMD / System / None)
+     * is treated as Bundler-incompatible across the full supported TS range.
+     *
+     *   - Node16 / NodeNext require `module: Node16` or `module: NodeNext` (TS5110).
+     *     ts-jest never emits those module kinds, so these user-supplied values are
+     *     substituted: to Bundler when the forced module is in the
+     *     Bundler-compatible set, or to Node10 otherwise. (Pairing Bundler with a
+     *     non-ES module raises TS5095, and Node10 is the only kind that has been
+     *     valid with non-ES modules across every TypeScript version ts-jest
+     *     supports.)
+     *
+     *   - User-supplied Bundler with a non-Bundler-compatible forced module is
+     *     also TS5095 on the supported TS range — substitute Node10. (TypeScript
+     *     6 relaxed this for `module: CommonJS` specifically; that relaxation is
+     *     deliberately not encoded here so behavior stays consistent across the
+     *     full peerDependency range. See `isBundlerCompatibleModuleKind` for the
+     *     follow-up pointer.)
+     *
+     *   - Anything else (Node10 / Classic / unset) passes through or falls back
+     *     to Node10. These pairings are valid with every forced module kind.
+     *
+     * Compatibility: `ModuleResolutionKind.Bundler` was introduced in
+     * TypeScript 5.0. ts-jest declares `peerDependencies: { typescript: ">=4.3 <7" }`,
+     * so the Bundler member is `undefined` at runtime on TypeScript 4.3 - 4.9.
+     * The Node16/NodeNext substitution falls back to Node10 in that case
+     * (`bundlerResolution` below) to keep the function deterministic across the
+     * full supported range. Users on TypeScript < 5 can never have set Bundler in
+     * tsconfig (the parser rejects it), so the user-supplied-Bundler branch is
+     * unreachable there and needs no separate guard.
+     */
+    resolveCompatibleModuleResolution(forcedModule, userResolution) {
+        const node10Default = this._ts.ModuleResolutionKind.Node10 ?? this._ts.ModuleResolutionKind.NodeJs;
+        if (userResolution === undefined) {
+            return node10Default;
+        }
+        const { Node16, NodeNext, Bundler } = this._ts.ModuleResolutionKind;
+        const bundlerResolution = Bundler ?? node10Default;
+        const canUseBundler = this.isBundlerCompatibleModuleKind(forcedModule);
+        if (userResolution === Node16 || userResolution === NodeNext) {
+            return canUseBundler ? bundlerResolution : node10Default;
+        }
+        if (userResolution === Bundler && !canUseBundler) {
+            return node10Default;
+        }
+        return userResolution;
+    }
+    /**
+     * TypeScript pairs `moduleResolution: bundler` only with ES-module module
+     * kinds (`ES2015` / `ES2020` / `ES2022` / `ESNext`) or `Preserve` (added in
+     * TypeScript 5.4). Pairing `bundler` with `CommonJS`, `AMD`, `UMD`, `System`,
+     * or `None` raises TS5095. Used by `resolveCompatibleModuleResolution` to
+     * gate the `Node16` / `NodeNext` → `Bundler` substitution and the
+     * user-supplied-`Bundler` pass-through, so neither path emits an invalid
+     * pair when the user has selected a non-ES `module`.
+     *
+     * Note: TypeScript 6.0 relaxed this restriction for `module: CommonJS`
+     * specifically (`CommonJS` + `Bundler` is now a valid pair on TS ≥ 6); the
+     * other non-ES module kinds (`AMD` / `UMD` / `System` / `None`) remain
+     * Bundler-incompatible on every TypeScript version. The TS 6 relaxation is
+     * intentionally not encoded here to keep behavior consistent across the full
+     * peerDependency range (`>=4.3 <7`); honoring it can ride in as a follow-up
+     * once the TS 6 baseline lands.
+     *
+     * @see https://www.typescriptlang.org/tsconfig/#moduleResolution
+     */
+    isBundlerCompatibleModuleKind(moduleKind) {
+        const M = this._ts.ModuleKind;
+        if (moduleKind === M.ESNext || moduleKind === M.ES2015 || moduleKind === M.ES2020 || moduleKind === M.ES2022) {
+            return true;
+        }
+        // `ModuleKind.Preserve` was introduced in TypeScript 5.4; on older
+        // TypeScript versions the property is `undefined` at runtime.
+        if (M.Preserve !== undefined && moduleKind === M.Preserve) {
+            return true;
+        }
+        return false;
+    }
+    /**
+     * Pass `customConditions` through unchanged when the resolved
+     * `moduleResolution` is one of the kinds that supports it (`Bundler`,
+     * `Node16`, `NodeNext`); strip it otherwise. TypeScript raises TS5098
+     * when `customConditions` is paired with any other resolution kind
+     * (verified empirically against TypeScript 5.9.3 with `tsc -p`).
+     *
+     * Before #4198 the surrounding `fixupCompilerOptionsForModuleKind`
+     * unconditionally cleared `customConditions` because the hardcoded
+     * `Node10` override always made it incompatible. After #4198 the
+     * resolved `moduleResolution` can be `Bundler` (e.g. when the user
+     * has `Node16`/`NodeNext` paired with an ES-family `module`), so we
+     * need to preserve the user's `customConditions` in that case rather
+     * than silently dropping it.
+     *
+     * @see https://www.typescriptlang.org/tsconfig/#customConditions
+     */
+    preserveCustomConditionsIfCompatible(resolvedModuleResolution, userCustomConditions) {
+        const R = this._ts.ModuleResolutionKind;
+        const supportsCustomConditions = resolvedModuleResolution === R.Bundler ||
+            resolvedModuleResolution === R.Node16 ||
+            resolvedModuleResolution === R.NodeNext;
+        return supportsCustomConditions ? userCustomConditions : undefined;
+    }
     getCompiledOutput(fileContent, fileName, options) {
         const isEsmMode = this.configSet.useESM && options.supportsStaticESM;
         this._compilerOptions = this.fixupCompilerOptionsForModuleKind(this._initialCompilerOptions, isEsmMode);
         const moduleKind = this._initialCompilerOptions.module;
         const currentModuleKind = this._compilerOptions.module;
+        // Without this, a Program rebuilt for one compile's module kind would be
+        // reused on the next compile when that compile expects a different kind.
+        const moduleKindChangedSinceLastCompile = this._previousCompiledModuleKind !== undefined && this._previousCompiledModuleKind !== currentModuleKind;
+        this._previousCompiledModuleKind = currentModuleKind;
         if (this._languageService) {
             if (constants_1.JS_JSX_REGEX.test(fileName) && !this._compilerOptions.allowJs) {
                 this._logger.warn({ fileName: fileName }, (0, messages_1.interpolate)("Got a `.js` file to compile while `allowJs` option is not set to `true` (file: {{path}}). To fix this:\n  - if you want TypeScript to process JS files, set `allowJs` to `true` in your TypeScript config (usually tsconfig.json)\n  - if you do not want TypeScript to process your `.js` files, in your Jest config change the `transform` key which value is `ts-jest` so that it does not match `.js` files anymore" /* Errors.GotJsFileButAllowJsFalse */, { path: fileName }));
@@ -151,7 +288,7 @@ class TsCompiler {
             }
             this._logger.debug({ fileName }, 'getCompiledOutput(): compiling using language service');
             // Must set memory cache before attempting to compile
-            this._updateMemoryCache(fileContent, fileName, currentModuleKind === moduleKind);
+            this._updateMemoryCache(fileContent, fileName, currentModuleKind === moduleKind && !moduleKindChangedSinceLastCompile);
             const output = this._languageService.getEmitOutput(fileName);
             const diagnostics = this.getDiagnostics(fileName);
             if ((0, transpile_module_1.isModernNodeModuleKind)(this._initialCompilerOptions.module)) {
@@ -360,11 +497,17 @@ class TsCompiler {
      * @internal
      */
     _resolveModuleName(moduleNameToResolve, containingFile) {
+        const getImpliedNodeFormat = this._ts.getImpliedNodeFormatForFile;
+        const resolutionMode = typeof getImpliedNodeFormat === 'function'
+            ? getImpliedNodeFormat(containingFile, undefined, 
+            // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
+            this._moduleResolutionHost, this._compilerOptions)
+            : undefined;
         return this._ts.resolveModuleName(moduleNameToResolve, containingFile, this._compilerOptions, 
         // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
         this._moduleResolutionHost, 
         // eslint-disable-next-line @typescript-eslint/no-non-null-assertion
-        this._moduleResolutionCache);
+        this._moduleResolutionCache, undefined, resolutionMode);
     }
     /**
      * @internal

package/dist/legacy/ts-jest-transformer.js

@@ -189,11 +189,14 @@ class TsJestTransformer {
                 const transpiledResult = typescript_1.default.transpileModule(sourceText, {
                     compilerOptions: {
                         ...configs.parsedTsConfig.options,
-                        module: transformOptions.supportsStaticESM && transformOptions.transformerConfig.useESM
+                        module: transformOptions.supportsStaticESM && transformOptions.transformerConfig?.useESM
                             ? typescript_1.default.ModuleKind.ESNext
                             : typescript_1.default.ModuleKind.CommonJS,
                     },
-                    fileName: sourcePath,
+                    // .mjs fileName causes ts.transpileModule to preserve ESM syntax even with module: CommonJS
+                    fileName: transformOptions.supportsStaticESM && transformOptions.transformerConfig?.useESM
+                        ? sourcePath
+                        : sourcePath.replace(/\.mjs$/, '.js'),
                 });
                 result = {
                     code: (0, compiler_utils_1.updateOutput)(transpiledResult.outputText, sourcePath, transpiledResult.sourceMapText),

package/dist/transformers/hoist-jest.js

@@ -62,10 +62,17 @@ function factory({ configSet }) {
         if (statements.length <= 1) {
             return statements;
         }
-        return statements.sort((stmtA, stmtB) => isJestGlobalImport(stmtA) ||
-            (isHoistableStatement(stmtA) && !isHoistableStatement(stmtB) && !isJestGlobalImport(stmtB))
-            ? -1
-            : 1);
+        // Return 0 for same-category statements so stable sort preserves source
+        // order, the previous `-1 | 1`-only comparator violated ECMA's consistent
+        // comparison contract and let V8 reorder same-category pairs.
+        const priority = (stmt) => {
+            if (isJestGlobalImport(stmt))
+                return 0;
+            if (isHoistableStatement(stmt))
+                return 1;
+            return 2;
+        };
+        return statements.sort((a, b) => priority(a) - priority(b));
     };
     const createVisitor = (ctx, _) => {
         const visitor = (node) => {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ts-jest",
-  "version": "29.4.9",
+  "version": "29.4.10",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
   "type": "commonjs",
@@ -57,7 +57,7 @@
     "json5": "^2.2.3",
     "lodash.memoize": "^4.1.2",
     "make-error": "^1.3.6",
-    "semver": "^7.7.4",
+    "semver": "^7.8.0",
     "type-fest": "^4.41.0",
     "yargs-parser": "^21.1.1"
   },
@@ -96,9 +96,9 @@
     "@eslint/compat": "^1.4.1",
     "@eslint/eslintrc": "^3.3.5",
     "@eslint/js": "^9.39.4",
-    "@jest/globals": "^30.3.0",
-    "@jest/transform": "^30.3.0",
-    "@jest/types": "^30.3.0",
+    "@jest/globals": "^30.4.1",
+    "@jest/transform": "^30.4.1",
+    "@jest/types": "^30.4.1",
     "@types/babel__core": "^7.20.5",
     "@types/fs-extra": "^11.0.4",
     "@types/jest": "^29.5.14",
@@ -107,16 +107,16 @@
     "@types/lodash.memoize": "^4.1.9",
     "@types/lodash.set": "^4.3.9",
     "@types/micromatch": "^4.0.10",
-    "@types/node": "20.19.37",
+    "@types/node": "20.19.41",
     "@types/semver": "^7.7.1",
     "@types/yargs": "^17.0.35",
     "@types/yargs-parser": "21.0.3",
-    "@typescript-eslint/eslint-plugin": "^8.57.2",
-    "@typescript-eslint/parser": "^8.57.2",
-    "babel-jest": "^30.3.0",
-    "conventional-changelog-angular": "^8.3.0",
+    "@typescript-eslint/eslint-plugin": "^8.59.3",
+    "@typescript-eslint/parser": "^8.59.3",
+    "babel-jest": "^30.4.1",
+    "conventional-changelog-angular": "^8.3.1",
     "conventional-changelog": "^7.2.0",
-    "esbuild": "~0.27.4",
+    "esbuild": "~0.28.0",
     "eslint": "^9.39.4",
     "eslint-config-prettier": "^10.1.8",
     "eslint-plugin-import": "^2.32.0",
@@ -125,18 +125,18 @@
     "eslint-plugin-prettier": "^4.2.5",
     "execa": "5.1.1",
     "fast-glob": "^3.3.3",
-    "fs-extra": "^11.3.4",
+    "fs-extra": "^11.3.5",
     "globals": "^16.5.0",
     "husky": "^9.1.7",
-    "jest": "^30.3.0",
+    "jest": "^30.4.2",
     "js-yaml": "^4.1.1",
     "lint-staged": "^15.5.2",
-    "memfs": "^4.57.1",
+    "memfs": "^4.57.2",
     "prettier": "^2.8.8",
     "rimraf": "^5.0.10",
     "ts-node": "^10.9.2",
     "typescript": "~5.9.3",
-    "typescript-eslint": "^8.57.2"
+    "typescript-eslint": "^8.59.3"
   },
   "engines": {
     "node": "^14.15.0 || ^16.10.0 || ^18.0.0 || >=20.0.0"