Released Jest upgrade eliminating braces 3.0.3 paths from Jest 29.7.0

[alaaomran8234]

Our independent native-test project uses jest@29.7.0. Its historical lock contains:

• Test-project root → jest@29.7.0 → @jest/core ^29.7.0, resolved 29.7.0 → micromatch ^4.0.4, resolved 4.0.8 → braces ^3.0.3, resolved 3.0.3.
• The same core also depends through ^29.7.0 on @jest/transform, jest-config, jest-haste-map and jest-message-util, each resolved to 29.7.0; each introduces the same micromatch/braces suffix.

Is there a named released Jest combination that removes these affected paths without overrides or disabling test coverage? Please identify exact versions, remaining transitive blockers and migration/engine constraints. We will separately confirm compatibility with Medusa’s test-utils maintainers. These paths are installed-graph evidence, not a runtime exploit reproduction; Medusa’s dependency changes alone would not resolve them.

[mgkvibez]

Yes — there is a named combination: Jest 30.5.x.

I checked the registry for the exact packages you listed:

• @jest/core 30.5.2 — micromatch: not a dependency anymore
• @jest/transform 30.5.2 — micromatch: gone
• jest-config 30.5.2 — micromatch: gone
• jest-haste-map 30.5.1 — micromatch: gone
• jest-message-util 30.5.1 — micromatch: gone

The micromatch → braces ^3.0.3 suffix that 29.7.0 carries through all five packages doesn't exist anywhere in the 30.x line, so the affected path is removed at the source — no npm overrides, no coverage changes.

Two things worth knowing before you jump:

1. You can't fix this in place on 29.7.0 — braces 3.x tops out at 3.0.3 on the registry (there is no 3.0.4+ to refresh your lock to), so "historical lock + micromatch ^4.0.4" can never resolve past it. 30.x is the actual fix.

2. Verify your own tree after upgrading — micromatch can still show up from non-Jest dependencies in your project, and if your scanner flags any of those, that's a separate path to handle.