pinned peer dependencies create unresolvable dependencie cycle

[dotKuro]

What is this issue about?

Currently eslint-conifg-es and some of its dependencies are installed as peer dependencies. This decision was made, because after version 9.0.0 of the roboter the resolution of the eslint plugins was broken. It was no longer possible to execute eslint from within roboter, because the plugins wouldn't be found. We assume this is because before that version roboter was executed with the current working directory being its own package where now it is the project root of the package that has roboter installed. Installing the plugins as deep dependencies fixed this issue, because they would be installed directly as dependencies to the root project and now could be resolved correctly.

Eventually time unveiled some other issues with this approach:

• dependabot won't bump version of packages listed in the peerDependencies section
• Updating these version manually creates a dependency cycle, because eslint-config-es has roboter as a development dependency and roboter has eslint-config-es as dependency

What needs to be done to solve this?

There are multiple possible solutions to this:

1. Remove roboter as dependency of eslint-config-es

This would break the dependency cycle. In order to do this, we would need to build the eslint-config-es project with another tool, probably with tsc directly. This would not solve all the issues, because dependabot still struggles with peer-dependencies.

2. Find a way to restore the old behavior

If we find a way to execute roboter as it was done prior to version 9.0.0, we could return to using normal dependencies. We think it might be enough to explicitly set the current working directory to the roboter directory. This needs further investigation though