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
Is your feature request related to a problem? Please describe.
TestKit support lib is great but it only supports a small set of elements to be used in the project.
It is nice that you can write project builds so easily from Kotlin code but there are not a lot of options to add custom code.
For example, I have stumbled recently with not being able to add imports to build.gradle.kts or adding custom code inside the dependency or repository block.
Describe the solution you'd like
After thinking about this it would be great to change all rendered elements to be open, so we can implement our own objects that render the code as needed.
Describe alternatives you've considered
Another alternative would be to add more options to pass custom code or create more elements, but it will be difficult to maintain/test and will add a lot of complexity to the API it is probably impossible to model the whole language that can be used in builds without writing another language.
Additional context
My use case was trying to replicate what we use in our projects which is something like this:
In this case imports are just impossible to write with the current API and creating a custom BuildScriptBlock would allow it.
The actual call can be rendered with the current logic in a hacky way.
Anyway, we will be moving to a catalog and bundles so we will move to a more standard practice.
But imports are needed for other use cases and there is no way in Kotlin to call extension functions without an import (except via reflection)
The text was updated successfully, but these errors were encountered:
friscoMad
changed the title
[TestKit Plugin]
[TestKit Plugin] Open Rendered elements to be able to create custom ones
Mar 15, 2024
Thanks for the issue. I actually think it would make sense to add a new data type for imports, since they have to go at the top of a file, are semantically separable from other elements, and are a common-enough use-case to be worth supporting directly. The rest of this request, opening up the objects to permit custom rendering, is also interesting and I will think about it. Do you have any other use-cases in mind?
Is your feature request related to a problem? Please describe.
TestKit support lib is great but it only supports a small set of elements to be used in the project.
It is nice that you can write project builds so easily from Kotlin code but there are not a lot of options to add custom code.
For example, I have stumbled recently with not being able to add imports to
build.gradle.kts
or adding custom code inside the dependency or repository block.Describe the solution you'd like
After thinking about this it would be great to change all rendered elements to be open, so we can implement our own objects that render the code as needed.
Describe alternatives you've considered
Another alternative would be to add more options to pass custom code or create more elements, but it will be difficult to maintain/test and will add a lot of complexity to the API it is probably impossible to model the whole language that can be used in builds without writing another language.
Additional context
My use case was trying to replicate what we use in our projects which is something like this:
In this case imports are just impossible to write with the current API and creating a custom BuildScriptBlock would allow it.
The actual call can be rendered with the current logic in a hacky way.
Anyway, we will be moving to a catalog and bundles so we will move to a more standard practice.
But imports are needed for other use cases and there is no way in Kotlin to call extension functions without an import (except via reflection)
The text was updated successfully, but these errors were encountered: