Consider rewriting ember-template-lint as an ESLint language plugin

[bmish]

The ESLint language plugin proposal was only just released: eslint/rfcs#99

But matching ESLint's behavior/functionality has been one of our long-term goals, and a direction we've been moving in for a while.

We should evaluate whether the ESLint proposal meets our needs and whether it would be practical and beneficial to use an ESLint language plugin under the hood.

Please comment on whether you think this is a good idea or not, even possible, or potential issues it could run into. Add a plus one vote emoji is you agree.

Requirements:

• ESLint needs to support AST-based autofixing (feat: ESLint Language Plugins eslint/rfcs#99 (comment))

Related:

• add meta information to rules #943 (comment)

Disclaimer: this ESLint language plugin feature isn't likely to be ready for a while. ember-template-lint is also very large (100+ rules) and has very limited maintainer bandwidth for any potential migration. In the mean time, we should continue our efforts to match ESLint behavior/functionality to prepare for any such migration.

[chriskrycho]

Extremely yes please. (cc. @gabrielcsapo!) This will make it much easier for us to have template linting integrated with editors, without needing custom language server implementation. Additionally, it feels like a significant gap not to have it when using .gjs/.gts files!

[gabrielcsapo]

+100000, thanks for the cc @chriskrycho 🙌

[grconrad]

+1

[colenso]

👍

[patricklx]

i've made a eslint-plugin for this: https://github.com/patricklx/eslint-plugin-ember-template-lint
it can also run on hbs and gts/gjs files and apply fixes.
It currently uses synckit, like prettier does, because ember-template-lint uses esm.
eslint already support a new config file that supports esm, but didnt investigate into that.
note that ember-template-lint actually already supports gts/gjs, what the eslint plugin does on top is also to check the scope to validate the no-implicit-this message.