build: migrate to Nx v17 inc deps

[BioPhoton]

This PR updates Nx packages. In addition to the new package versions a couple of refactoring's needed to be done to make it work.

Included changes:

• package updates
• refactoring of the nx-plugin code due to changes of the nx.json structure
• refactorings of the plugin-eslint package due to dependency changes

Included changes to discuss:

• the current PR includes a bigger refactoring of the tests in package-eslint
• the number of rules got reduces
• test setup per case

[BioPhoton]

I don't really get why the eslint-plugin tests fail... @vmasek any clue?

[BioPhoton]

I know now why the tests where failing. They rely on real eslint setup and the ouatput data changed.
@matejchalk I already created #255 and #254 and updated #224

What would be the minimum fix to make this PR turn 🟢?

Update:
For now I went with 8f15475 let me know what you think

Update:
I should not change the eslint setup in the package as it tests the integration of the other plugins

[matejchalk]

@BioPhoton Why is this a precondition for #126? Are we not able to publish packages until we're on Nx 17? 🤨 That would surprise me, because I was able to publish the @code-pushup/portal-client using @jscutlery/semver and Nx 16 without any issues.

[BioPhoton]

I wanted to get the update in before, but also decided today that its not a good idea.

[BioPhoton]

Ok, I gave the test refactoring a try based on our discussions with @Tlacenka. It's not perfect but much more entangles and smaller in rules.

@matejchalk let me know if I can polish this version or if I can adopt it.

If it is OK I would also try to generate the eslint files dynamically instead of having them in the fs.

[matejchalk]

Sorry, but the PR scope is too big. Refactoring the plugin-eslint tests isn't necessary to update Nx. Please revert those changes and just run npx nx test plugin-eslint -u to update the snapshot.

The fact that the tests failed after a major update isn't a bad thing, in my opinion. It gives us visibility into the impact of those changes.

[matejchalk]

The migrations.json file shouldn't be committed.

[BioPhoton]

Yes! Also documented here:
https://nx.dev/core-features/automate-updating-dependencies#step-3-cleaning-up

[BioPhoton]

Just learned that it is not needed anymore

[BioPhoton]

@matejchalk
I will first refactor the plugin-eslint tests and then update Nx.

[matejchalk]

I will first refactor the plugin-eslint tests and then update Nx.

But why? 😅 The priorities are completely the opposite in my opinion. I'm not even convinced the ESLint tests need to be refactored (would be good to get @Tlacenka's opinion on this), and it surely isn't a blocker for updating Nx (npx nx test plugin-eslint -u is the only necessary step, I believe).

I honestly don't like having to decline your PRs, but when you decide to make big changes before first consulting it with us (e.g. on refinement), then I'm afraid it's gonna keep happening 😞

[Tlacenka]

@BioPhoton Ok, I gave the test refactoring a try based on our discussions with @Tlacenka. It's not perfect but much more entangles and smaller in rules.

@matejchalk I'm not even convinced the ESLint tests need to be refactored (would be good to get @Tlacenka's opinion on this)

The plugin-eslint package in the original version is in my opinion sufficiently covered by both unit (internal logic) and integration (initiation and executing the runner) tests.

I am unfortunately unable to determine which changes are truly necessary due to the updated nx version. The ESLint rules and results seem to be different, variables renamed.

Should the changes be done as a part of #255 , they should in my opinion be first investigated in detail and any targetted changes should be scoped and prioritised separately (otherwise the issue could get bloated easily), not as a part of this PR.