You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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
The text was updated successfully, but these errors were encountered:
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 version9.0.0
of theroboter
the resolution of theeslint
plugins was broken. It was no longer possible to executeeslint
from withinroboter
, because the plugins wouldn't be found. We assume this is because before that versionroboter
was executed with the current working directory being its own package where now it is the project root of the package that hasroboter
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:
peerDependencies
sectioneslint-config-es
hasroboter
as a development dependency androboter
haseslint-config-es
as dependencyWhat needs to be done to solve this?
There are multiple possible solutions to this:
roboter
as dependency ofeslint-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 withtsc
directly. This would not solve all the issues, because dependabot still struggles with peer-dependencies.If we find a way to execute
roboter
as it was done prior to version9.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 thoughThe text was updated successfully, but these errors were encountered: