• Fix parser preset merging when user provides partial overrides
• Always resolve extended string parser presets for proper configuration
• Preserve user properties during nested parserOpts unwrapping
• Add integration and unit tests for partial preset override scenario

Always resolve extended string parser presets

• Remove !context.parserPreset guard to always resolve string parser presets from extended configs
• Update comment to explain why extended presets must always be resolved for proper merging
• Fix assignment to use c.parserPreset instead of config.parserPreset for consistency
• Update type annotation to allow ParserPreset objects in addition to strings

@commitlint/resolve-extends/src/index.ts

Preserve user properties during parserOpts unwrap

• Preserve user-provided properties during nested parserOpts unwrapping
• Use destructuring to extract inner parserOpts while keeping outer properties
• Merge inner and outer properties instead of replacing outer object entirely
• Add comment explaining the fix for issue #4640

@commitlint/load/src/utils/load-parser-opts.ts

Add unit test for partial preset merge

• Add unit test for partial user parserPreset merging with extended preset
• Verify that user-provided issuePrefixes merge with extended headerPattern
• Test that all properties from both configs are present in result
• Reference issue #4640 in test comment

@commitlint/resolve-extends/src/index.test.ts

Description

loadExtends now assigns c.parserPreset = parserPreset after dynamicImport(), but
dynamicImport() can return the raw imported module namespace object when there is no truthy
default export. ESM module namespace objects are immutable, so this assignment can throw a
TypeError and break config resolution for certain extended configs.

Code

@commitlint/resolve-extends/src/index.ts[R153-156]

+		if (typeof c === "object" && typeof c.parserPreset === "string") {
			const resolvedParserPreset = resolveFrom(c.parserPreset, cwd);

			const parserPreset: ParserPreset = {

Evidence

dynamicImport() explicitly falls back to returning the full imported value (module namespace)
when it doesn’t find a truthy default export; loadExtends() then mutates the returned value
(c) by assignment to c.parserPreset. If the fallback path returns an ESM module namespace
object, that object is not writable/extensible, so the assignment can throw and stop loading
extends.

@commitlint/resolve-extends/src/index.ts[16-25]
@commitlint/resolve-extends/src/index.ts[142-163]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`@commitlint/resolve-extends` mutates `c` (the value returned from `dynamicImport`) by assigning `c.parserPreset = parserPreset`. When `dynamicImport()` falls back to returning the raw imported module object (e.g., an ESM module namespace object with no default export), this assignment can throw and abort config resolution.

### Issue Context
`dynamicImport()` returns `(default && default) || imported`, so if `default` is missing or falsy it returns `imported`. `imported` may be an ESM module namespace object, which is not safely mutable.

### Fix Focus Areas
- @commitlint/resolve-extends/src/index.ts[142-168]

### Suggested fix
- Change the code to avoid mutating `c` directly:
 - Create `const cMutable = typeof c === 'object' && c !== null ? { ...(c as any) } : c;`
 - When resolving string `parserPreset`, assign to `cMutable.parserPreset` (or create `const nextConfig = { ...cMutable, parserPreset }`).
 - Ensure recursion and returned configs use the mutable/copied object (`loadExtends(nextConfig, ctx)` and push `nextConfig`) rather than the original imported value.
- Add (or adjust) a unit test where `dynamicImport` returns an object that simulates an ESM namespace (e.g., `Object.freeze({ parserPreset: './preset' })`) to assert no throw.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools