Codemod: migrate {{! template-lint-disable }} comments to ESLint-native directives#3
Open
johanrd wants to merge 8 commits into
Conversation
…ecommended
Adds `eslint-plugin-ember/configs/recommended-template` — an opt-in flat
config that enables the same ~94 template rules as ember-template-lint's
recommended preset, making it easy to drop ember-template-lint and keep
equivalent coverage.
The config is intentionally not part of the main `recommended` export.
Template linting is a separate concern and many projects will want to
adopt it incrementally or tune individual rules (e.g. no-bare-strings
allowlists, no-inline-styles) before committing to the full set.
Unlike ember-template-lint's recommended.js, this config carries no
gjs/gts overrides. The original ETL overrides existed because template-
lint has no JS scope tracker and couldn't distinguish `{{foo}}` (a JS
binding) from `{{foo}}` (an implicit-this lookup). The ported rules in
this plugin walk ESLint's scope chain directly, so no-implicit-this and
no-curly-component-invocation already skip JS-scoped identifiers, and
no-builtin-form-components / no-unknown-arguments-for-builtin-components
explicitly check for imports in gjs/gts files. The overrides would only
suppress correct behaviour.
🏎️ Benchmark Comparison
Full mitata output |
15 tasks
Adds a one-shot codemod that rewrites ember-template-lint comment
directives to ESLint-native equivalents, so projects migrating to
eslint-plugin-ember can keep their in-template suppression comments
working without reimplementing ETL's directive semantics as an ESLint
processor.
Scope is grounded in what ETL itself parses today
(lib/rules/_base.js:247-337):
- Mustache comments only ({{! ... }} and {{!-- ... --}}); HTML
comments are skipped because ETL does not honour directives in
them either.
- template-lint-disable / template-lint-enable rewrite to
eslint-disable / eslint-enable with rules remapped from the bare
ETL name (no-foo) to the plugin rule ID (ember/template-no-foo).
- template-lint-disable-tree / -enable-tree and
template-lint-configure[-tree] are left unchanged with a warning;
they have no ESLint equivalent (tree scope / in-template rule
config respectively).
- Unknown rule names are still rewritten so they surface in lint
output, with a warning.
Includes a CLI entry (dry-run by default, --write to apply) and 26
tests covering simple and block forms, multi-line block comments,
quoted and whitespace-separated rule lists, skip+warn paths, line
numbers in warnings, idempotency, and context preservation.
README gains a "Rewriting {{! template-lint-disable }} comments"
subsection under the ETL migration guide.
johanrd
force-pushed
the
feat/migrate-template-lint-directives-codemod
branch
from
ce3b401 to
8d479a5
Compare
…RLF)
Layer the rule-name validator: accept a token if the plugin already has a
rule with that name, or if it looks like kebab-case with a hyphen. The
previous hyphen-only check had a false negative for real single-word
rules — specifically `template-quotes` — which would have left user
comments like {{! template-lint-disable quotes }} untransformed. The
layered validator still rejects plain prose (`extra text`) because those
tokens are neither known plugin rules nor hyphenated.
Swap parseRules replace order: strip trailing commas before paired
quotes, so `'foo',` → `foo` instead of `'foo'`. Comment the rationale.
Strengthen the CRLF test to also pressure computeLine across CRLF
line endings, not just preservation.
Document the "continue after input error" CLI choice so a future reader
doesn't mistake it for a missing early-exit.
johanrd
force-pushed
the
feat/recommended-template-config
branch
4 times, most recently
from
37c416d to
7bc1404
Compare
Drops the regex comment scanner in favor of
root.find('GlimmerMustacheCommentStatement') + path.replace(), now that
ember-estree 0.4.3 (NullVoxPopuli/ember-estree#31) keeps mustache comment
nodes in the template body with semantic types and a longForm boolean
that drives delimiter re-emission.
Script is now ESM (.mjs) since zmod and zmod-ember are ESM-only.
Test file uses import but keeps the .js extension — vitest handles it.
transform takes a filePath option and routes to { templateOnly: true }
for .hbs vs { filePath } for .gjs/.gts.
Known limitation: for HBS the parser exposes each comment twice (once
in ast.body, once in a parallel comments array). Worked around with
dedupe-by-node.start. Filing upstream.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
This is part of a series where Claude has audited
eslint-plugin-emberagainst jsx-a11y, vuejs-accessibility, angular-eslint, lit-a11y and html-validate,ember-template-lint, and the HTML and WCAG specs.Cowritten by claude
Why a codemod instead of a processor
PR ember-cli#2627 introduced a runtime processor that parses
{{! template-lint-disable }}comments out of template text and filters ESLint messages to match ETL's semantics. The follow-up onfeat/template-lint-enable-range-semanticswidened that to block scope.That works, but it reimplements functionality ESLint already provides:
{{! eslint-disable rule }},{{! eslint-disable-next-line rule }}, and{{! eslint-disable rule }}…{{! eslint-enable rule }}already work today inside mustache comments in.gjs/.gts/.hbsfiles (covered by tests added in commitsa077ffe7and5c433af4onfeat/template-lint-enable-range-semantics). The only thing missing for ETL migrators is the comment name. A codemod fixes that once, at migration time, with zero ongoing plugin code to maintain and no second directive-scope model to keep in sync.The rule-name mapping is deterministic by convention: every ported template rule lives at
lib/rules/template-<etl-name>.js, so ETL'sno-foomaps cleanly to this plugin'sember/template-no-foo. Rules that don't follow that convention (if any future port deviates) surface as unknown-rule warnings.Scope
Grounded in what ETL itself parses today (
lib/rules/_base.js:247-337):.hbs,.gjs,.gts.{{! ... }}and{{!-- ... --}}). HTML comments are skipped because ETL doesn't honour directives in them either (_base.js:197-201registers aCommentStatementvisitor but attaches no instruction handler to it; onlyMustacheCommentStatementgets_processInstructionNodewired in at_base.js:247).template-lint-disable/template-lint-enable→eslint-disable/eslint-enable, with rule names remapped.template-lint-disable-tree/-enable-tree(ESLint has no tree scope) andtemplate-lint-configure[-tree](no in-template rule-config equivalent; must move to the flat config file)./, etc.): comment left unchanged with a warning. Prevents bogusember/template-extraoutput when a user writes{{!-- template-lint-disable no-bare-strings extra text --}}._base.js:27-39, 515): whitespace-split (not comma), paired quotes stripped viaunquote-style regex. Trailing commas are tolerated as a common migration typo.Example
template-lint-disable-treeandtemplate-lint-configureare left in place with a warning pointing at the line so users can resolve them manually.CLI
Accepts files or directories; directories are walked recursively, filtered to
.hbs/.gjs/.gts, excludingnode_modules,.git,dist,tmp,.cache.ENOENT/EACCESon inputs produce clean error messages and a non-zero exit code.Coverage vs
feat/template-lint-enable-range-semanticsThe processor-branch tests are integration tests (do real lint messages get suppressed?). The codemod tests are transformation tests (does the output text match?). Every processor-branch behavior has a codemod equivalent:
rewrites a simple mustache disable with no rulesrewrites a block mustache disabletemplate-lint-enablecloses the disable rangejoins multiple rule names with commashandles multiple simple comments on different linesember/template-no-bare-stringssuppressionDeliberate divergences
Two processor behaviors the codemod does not match:
template-lint-disable(e.g.{{! template-lint-disable no-undef }}). The processor'smatchesRule()accepted bare rule IDs and suppressed JS core rules. The codemod always prependsember/template-, sono-undef→ember/template-no-undef(warns as unknown). This was never real ETL behavior — ETL doesn't touch JS rules — so ETL-alignment is deliberate.{{! template-lint-disable ember/template-no-bare-strings }}). The validator rejects tokens containing/and leaves the comment unchanged with a warning. Rare in real ETL-migrating codebases.Gap
There is no end-to-end integration test that lints the rewritten output with real ESLint to confirm messages actually get suppressed. Low risk (ESLint's native directives are well-tested), but a real gap in the test pyramid. Happy to add if requested.
Tests
30 vitest tests covering:
{{!template-lint-disable...}}) normalized to{{! ... }}-treeandconfigure[-tree]skip + warn (one test per code path)template-lint-disable-next-line(not an ETL directive): left aloneAll pass.
Smoke-tested on a real file
Dry-run on
punch-card.gtsin a migrating consumer project cleanly rewrote two{{! template-lint-disable no-nested-interactive }}comments to their ESLint equivalents, zero warnings.Open questions for review
scripts/as a prototype. Options: (a) keep inscripts/and document the path in README, (b) add abin/entry topackage.jsonso it runs asnpx eslint-plugin-ember migrate-template-lint-directives, (c) a separate codemod package.-treeexpansion. MVP skips with a warning. AST-based expansion (parse template with@glimmer/syntax, synthesizeeslint-enableat parent element close) is possible but feels like a bad trade for rare cases.Checklist
pnpm vitest run tests/scripts/)Test plan
pnpm vitest run tests/scripts/locally and confirm green.gtsfile with ETL comments in dry-run, then apply, then lint — confirm the resulting{{! eslint-disable ember/template-... }}comments are honoured