I'm questioning why we will need to do this. Is there a pain that we are solving with this one? As far as I can see, the tooling as we have it now works. What benefits do we gain when rewriting all our tooling to nrwl plugins?

not rewriting – it is more how it is integrated in the nx workspace. It should be more a convert library to plugin. Then we can get rid of the "hacky" way how our own builders are getting built.
with a tsc --outdir /node_modules/dynatrace/barista-builders for example

We should always follow the guidelines of nx because it is an opinionated folder structure and otherwise the tooling does not work as expected

Please correct me if I"m wrong here, but currently the tooling does work as expected, does it not?

does not. We encounter problems with files do not getting linted and imported from tooling where we crush our dependency graph. Our tools are no libraries but no tools in the meaning of nrwl/nx. They are plugins so we should treat them as one. This should be tackled after @ffriedl89 workspace refactorings.

Okay then. As I understood the explanation that @ffriedl89 gave me:

• We had to move all our tools into the libs folder for #570 because nx has hard coded paths of apps and libs in their boundary linting rule
• Because we have moved tools into libs now, other linting rules of nx fail, because they disallow additional files in their libraryRoot (i.e. Dockerfile, ect. _files we depend on in some tool occations_)
• Nx provides with version 9 a new solution for these, because they apparently noticed, that there is a need for additional tooling. And their way of doing this is to add the tooling (which should not be considered a library), into a plugins folder where linting is less strict.

@tomheller perfect summary :D

This issue is stale, because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

This issue is stale, because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 5 days