Parsing error: Enabling "project" does nothing when "projectService" is enabled. You can remove the "project" setting"

[chabb]

Which @ngrx/* package(s) are the source of the bug?

eslint-plugin

Minimal reproduction of the bug/regression with instructions

The last version of typescript-eslint added this check
typescript-eslint/typescript-eslint#11333

This causes an issue, because the ngrx plugin always set the project property in its configs, so if we use projectService, we have an error.

Currently we do
delete ngrx.configs.all[1].languageOptions.parserOptions.project
to avoid this error, which is hacky.
It would be nice to have a better solutiion

Expected behavior

We should not have an error when we use the projectService option

Versions of NgRx, Angular, Node, affected browser(s) and operating system(s)

Node: 24

Other information

No response

I would be willing to submit a PR to fix this issue

• Yes
• No

[dangrussell]

If I'm reading how the generator works correctly, it should just be a matter of removing the two instances of this line:

project: './tsconfig.json',

from this file: https://github.com/ngrx/platform/blob/main/modules/eslint-plugin/scripts/generate-config.ts

[chabb]

The problem is that you have to handle two cases, one case when projectService is set to true, and one case when projectService is set to false, and I do not see how the ngrx eslint plugin can know about it

[timdeschryver]

I'm thinking about removing the parserOptions entirely, and leave it up to the user to configure it correctly.
Similar to https://typescript-eslint.io/users/configs/#projects-with-type-checking

I'm interested in hearing your opinions on this.
This will only affect the configs all, effects, signals.

[chabb]

I'm an eslint user, and I did not give it too much thoughts, so I might be missing some points. But for me, when a plugin exposes an all configuration, there are two different semantics:

1. I want all the rules of this plugin
   vs
2. I just want a config that 'works' out of the box

At the end I would stick the first semantic and let the user configure it correctly ( and maybe document it, so users will not be lost ) but the problem with the linting tools ( and with all oss tools ) is that most people configure them until it works and do not read the docs unless they are forced to do so... so people would expect the second semantics