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
Perhaps the API could use Coursier data types, since SBT, Mill, and a lot of other Scala tooling understand them.
Perhaps this module would be purely focused on determining breaking-ness of a change in dependencies, since I assume MiMa already has an SBT-independent API.
Since SBT doesn't use Coursier data types directly, it might be interesting to consider further decoupling the plugin, so that the settings and tasks are just a thin layer on top of an API that implements all the logic in plain Scala, but with SBT data types as applicable. This could make developing other SBT plugins on top easier.
I think this is general good advice for all SBT plugin authors. If others agree maybe it should be written somewhere prominent. Have a core, build-tool-agnostic layer on bottom, on top of that a build-tool-specific plain-scala "business logic" layer, and make the plugin with its settings and tasks a very thin layer on top of that. I don't know how many plugins are written like that though, if any...
The text was updated successfully, but these errors were encountered:
nafg
changed the title
Factor out SBT-independent core module
Idea: Factor out SBT-independent core module
Jan 6, 2022
See discussion in #119
Perhaps the API could use Coursier data types, since SBT, Mill, and a lot of other Scala tooling understand them.
Perhaps this module would be purely focused on determining breaking-ness of a change in dependencies, since I assume MiMa already has an SBT-independent API.
Since SBT doesn't use Coursier data types directly, it might be interesting to consider further decoupling the plugin, so that the settings and tasks are just a thin layer on top of an API that implements all the logic in plain Scala, but with SBT data types as applicable. This could make developing other SBT plugins on top easier.
I think this is general good advice for all SBT plugin authors. If others agree maybe it should be written somewhere prominent. Have a core, build-tool-agnostic layer on bottom, on top of that a build-tool-specific plain-scala "business logic" layer, and make the plugin with its settings and tasks a very thin layer on top of that. I don't know how many plugins are written like that though, if any...
The text was updated successfully, but these errors were encountered: