Extract rule: template-require-valid-named-block-naming-format

[NullVoxPopuli]

Split from #2371.

[NullVoxPopuli-ai-agent]

Review: template-require-valid-named-block-naming-format (PR #2616)

Comparison with ember-template-lint source

General correctness:

1. Error message difference: Original: 'Named blocks are required to use the "camelCase" naming format. Please change "foo-bar" to "fooBar".' ESLint version: 'Named block should be in camelCase format. Change "foo-bar" to "fooBar".' Different wording, but conveys the same information.

2. Missing fix support: The original ETL rule has isFixable: true and implements this.mode === 'fix' logic to auto-fix named block names. The ESLint version does not implement a fixer despite the original supporting it. Consider adding fixable: 'code' and a fix function in context.report().

3. dasherize implementation: The ESLint version uses str.replaceAll(/([A-Z])/g, '-$1').toLowerCase(). This would convert "fooBar" to "foo-bar" correctly, but would also convert "FooBar" to "-foo-bar" (leading dash). The original ETL imports from helpers/dasherize-component-name.js which may handle this edge case differently. Worth testing with PascalCase inputs.

4. camelize implementation: Splits on - and capitalizes. This correctly handles "foo-bar" → "fooBar". Edge case: "foo--bar" would produce "fooBar" (empty string between dashes gets capitalized as empty). The original ETL imports helpers/camelize.js which may behave differently.

5. parseConfig handling: The ESLint version accepts false and returns false (disabling the rule), but ESLint options schema doesn't allow false — the schema only allows 'camelCase' or 'kebab-case' strings. The parseConfig function has dead code paths for false and true that can never be reached through ESLint's option validation.

Scope analysis (gjs/gts):

Potential concern: The rule matches node.path.original === 'yield', 'has-block', and 'has-block-params'. In gjs/gts files, these are Glimmer keywords and cannot be shadowed by JS imports — yield, has-block, and has-block-params are built-in template keywords. So scope analysis is not needed here. However, it's worth noting that node.path.original access assumes a specific AST shape — ensure the Glimmer ESLint parser always provides .path.original for these node types.

Tests: Thorough coverage of both formats, both parsers, and various node types (MustacheStatement, SubExpression). Good.

Summary: Good migration. Consider adding auto-fix support to match the original, and verify the dasherize edge case with PascalCase inputs.

🤖 Automated review comparing with ember-template-lint source