• Fix incorrect mutable array types in rule configurations
• Change array types to readonly in scope-case and scope-enum rules
• Allow const assertions without unnecessary type casting

Make rule option arrays readonly

• Changed cases property in scope-case rule from TargetCaseType[] to readonly TargetCaseType[]
• Changed delimiters property in scope-case rule from string[] to readonly string[]
• Changed scopes property in scope-enum rule from string[] to readonly string[]
• Changed delimiters property in scope-enum rule from string[] to readonly string[]

@commitlint/types/src/rules.ts

Description

Only the object-based scope-case/scope-enum option shapes were updated to readonly, but the
array-form config types still require mutable arrays (string[], TargetCaseType[]). This means
as const configs like the PR description example can still fail type-checking, and internal code
still needs type assertions.

Code

@commitlint/types/src/rules.ts[R116-129]

	"scope-case":
		| CaseRuleConfig<V>
-		| ObjectRuleConfig<V, { cases: TargetCaseType[]; delimiters?: string[] }>;
+		| ObjectRuleConfig<
+				V,
+				{ cases: readonly TargetCaseType[]; delimiters?: readonly string[] }
+		  >;
	"scope-delimiter-style": EnumRuleConfig<V>;
	"scope-empty": RuleConfig<V>;
	"scope-enum":
		| EnumRuleConfig<V>
-		| ObjectRuleConfig<V, { scopes: string[]; delimiters?: string[] }>;
+		| ObjectRuleConfig<
+				V,
+				{ scopes: readonly string[]; delimiters?: readonly string[] }
+		  >;

Evidence

RuleConfigTuple is defined as a readonly tuple, which is exactly what as const produces, but
EnumRuleConfig/CaseRuleConfig still model the *value* as mutable arrays. The PR only makes the
object-based scopes/cases/delimiters properties readonly (good), yet the union types still include
EnumRuleConfig/CaseRuleConfig for the array-form, so the original as const friction remains.
This is evidenced by internal configs still requiring explicit type assertions for array-valued
rules.

@commitlint/types/src/rules.ts[54-90]
@commitlint/types/src/rules.ts[110-129]
@commitlint/config-conventional/src/index.ts[14-46]

Agent prompt

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

## Issue description
`RuleConfigTuple` is a readonly tuple, but many rule value types still use mutable arrays (e.g., `string[]`, `TargetCaseType[]`). This makes `as const` configs fail type-checking for the common array-form configs (including the PR description’s example), so the current change is only a partial fix.

## Issue Context
The PR updated only the *object-based* `scope-case`/`scope-enum` option object properties to `readonly ...[]`. However, the array-form configs are still typed as mutable arrays via `EnumRuleConfig` and `CaseRuleConfig`, and internal configs already need type assertions as a workaround.

## Fix Focus Areas
- @commitlint/types/src/rules.ts[54-90]
- @commitlint/types/src/rules.ts[110-129]
- @commitlint/rules/src/scope-enum.ts[5-10]
- @commitlint/rules/src/scope-case.ts[7-13]
- @commitlint/rules/src/header-case.ts[7-11]
- @commitlint/cz-commitlint/src/utils/rules.ts[59-74]
- @commitlint/config-conventional/src/index.ts[14-46]

## Suggested approach
1. Change `EnumRuleConfig` to use `readonly string[]` (and any similar array-valued rule types).
2. Change `CaseRuleConfig` to use `TargetCaseType | readonly TargetCaseType[]`.
3. Optionally align rule implementation generic signatures (e.g., `scopeEnum`, `scopeCase`, `headerCase`, etc.) to accept readonly arrays too.
4. Update internal helpers that narrow/return `string[]` (e.g., `enumRuleIsActive`, `getEnumList`) to work with readonly arrays (or widen appropriately) and remove now-unnecessary type assertions in internal config packages.

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