Extract rule: template-no-this-in-template-only-components

[NullVoxPopuli]

Split from #2371.

[NullVoxPopuli-ai-agent]

Review: template-no-this-in-template-only-components

Compared against the original ember-template-lint rule at lib/rules/no-this-in-template-only-components.js.

What's done well

• Core detection logic using GlimmerPathExpression with node.head?.type === 'ThisHead' is clean and correct.
• The auto-fix from this.foo to @foo is properly implemented.
• Built-in properties that shouldn't be auto-fixed are handled correctly (reported but not fixed).
• Tests cover the key cases from the original: basic this.foo, subexpressions, action helpers, and the elementId non-fixable case.
• Both ember-eslint-parser and ember-eslint-parser/hbs modes are tested.
• The originallyFrom metadata is a nice touch for traceability.

Differences from the original worth noting

1. Reduced BUILTIN_PROPERTIES list: The original ember-template-lint rule has a larger set of built-in properties that are excluded from auto-fix: action, actionContext, actionContextObject, concatenatedProperties, element, parentView, target -- in addition to the ones included here (elementId, tagName, ariaRole, class, classNames, classNameBindings, attributeBindings, isVisible). Some of these (like action, element, parentView) could cause incorrect fixes if auto-replaced with @action etc. Consider aligning the list with the original, or documenting why the reduced set is intentional.

2. No file-path-based detection: The original rule has sophisticated logic to determine whether a template is actually template-only by checking for a co-located component class file on disk (isTemplateOnlyComponent()). The ESLint version skips this entirely and flags all this usage in <template> tags. This is a significant behavioral difference. In gjs/gts, the ESLint rule can rely on AST context (class body vs module level) -- but the rule as written doesn't distinguish between <template> inside a class body vs at module level. This means this.foo inside a class component's <template> would be incorrectly flagged. This seems like a bug -- the rule should check whether the <template> is inside a class body (similar to what PR 2580 does with isInsideClassOrFunction).

3. validComponentExtensions config option: The original supports a validComponentExtensions config option (defaulting to ['.js', '.ts']). The ESLint version has schema: [] (no options). This is fine for a first pass but worth noting.

4. Error message: The original includes "...or create a component.js for this component" in the message. The ESLint version omits this, which is reasonable since gjs/gts files are self-contained.

Potential bug

The rule uses GlimmerPathExpression which fires for all <template> tags in the file, including those inside class bodies. A class component like:

class MyComponent extends Component {
  <template>{{this.name}}</template>
}

would be incorrectly flagged. The rule should check that the <template> is at module level (not inside a class or function) before reporting. Consider reusing the isInsideClassOrFunction helper from PR #2580.

Test coverage

• The valid case {{@foo}} is good. Consider adding a valid test for this inside a class body <template> to verify it's not flagged (once the bug above is fixed).
• Missing a test for this.foo.bar (nested property access) -- the fix should produce @foo.bar.

---

🤖 Automated review comparing with ember-template-lint source