Closed hlxid closed 4 years ago
I don't think a extra repository is worth it for expansions like this and maybe someday Kotlin so I would just put them in a subdirectory inside the api repo because it is just a small and optional abstraction layer for the java api.
For when this should be added as a dependency of a plugin project I think we have these two options:
Only when the project contains at least one .scala
file.
That way plugins coded in other languages don't have to deal with the scala library.
Only when enabled through some file
This should be doable with the .sbt
file, but I'm not 100% sure and it probably won't be that straightforward. We could also add a flag to the plugin.xml
file, but it is designed for metadata which the framework uses, not build stuff so thats not really fitting.
Option 2 has the advantage that the implicits can be disabled if they cause problems, but in my opinion that advantage might not be worth the effort getting this settable using the sbt file.
Comments or other ideas for when to enable implicits? @sebinside
I would propose a easy solution here. Implicits do not offer new functionality and should be as simple to use as possible.
Description
The plugin developing experience for plugins in scala can be greatly using implicits.
Some use cases:
These implicits can then be then imported by plugin developers to get a better developing experience.
The scala only features like these implicit could be put into a seperate sbt module which can be added by plugin developers and are automatically added if a plugins is generated using
sbt create
.References
request on discord by @justgerd