parserServices errors when using angular-eslint plugin

[arahuna]

Describe the bug
I work on a fairly large legacy Angular project, we use the angular-eslint plugin to lint both our TS and HTML files. Something about using the @angular-eslint/template/process-inline-template plugin for TS files while also using the @angular-eslint/template-parser parser for HTML files causes an error about needing to generate parserServices in component files with inline HTML.

To Reproduce
I've created a minimal repo to reproduce the issue: https://github.com/arahuna/betterer-inline-test-repo.

Simply run yarn install followed by yarn betterer to see the error.

Expected behavior
Betterer should run the ts lint test. Instead, it outputs this error

🔥 ts lint: Error while loading rule '@typescript-eslint/dot-notation': You have used a rule which requires parserServices to be generated. You must therefore provide a value for the        
"parserOptions.project" property for @typescript-eslint/parser.
Occurred while linting C:\Users\arahu\Documents\Random Programming
Stuff\betterer-inline-test-repo\src\app\inline-html\inline-html.component.ts\1_inline-template-inline-html.component.ts-1.component.html

Versions (please complete the following information):

• Betterer Version: 5.4.0
• Node Version: 14.20.0

Additional context
I believe this may be related to this issue #1012 but I'm not sure. The error messages are similar and they seem to be using Angular but It's unclear whether the errors are happening on inline HTML.

[work933k]

Did you ever find a solution? I'm also experience this issue..

[DudeRandom21]

Unfortunately our team did not find a solution. We did figure out a workaround though. We use inline templates pretty sparingly so it wasn't too difficult to just add some exclude patterns for the files that have inline templates. This does mean that we won't get the enforcement in those files but since they're so few we're not too worried about it.

If you're more worried about ignoring a handful of files you can probably fix the issues in those files then do some clever trickery with overrides in your eslint config matching specific file paths but this seemed like more work than it was worth in our case.

If on the other hand you use inline templates very extensively, then we don't really have a good workaround unfortunately.