How I SBT - VI

I had planned to finish the series with this post. But Plugin s wouldn’t let me. I am going to show you how to write/publish a SBT project that is a Plugin, and I will show a nifty trick. It is not a trick, it is what SBT can do like a piece of pie.

• How I SBT - build.sbt
• How I SBT - Settings & Tasks
• How I SBT - Plugins
• How I SBT - Build Code Organization
• How I SBT - Multi-module Builds
• How I SBT - Publishing a Plugin
• How I SBT - Final Edition - a la carte

Publishing a Plugin Project

I am sorry I don’t nothing new to tell you here other than all you have to do to publish a Plugin project is to set sbtPlugin := true 🤷‍♂️. Essentially, everything else you read in the previous posts applies to a Plugin project, additionally setting sbtPlugin.

Well, what is a Plugin project or library? Or what does it mean to publish a Plugin? All it means is that you can publish your project similarly to any other library, which we can use in plugins.sbt in the addSbtPlugin call.

A Plugin library thus published exposes Plugin s to the project it is applied on. Note Plugin s. The Plugin library may have multiple Plugin s for the host project to use. Some automatically enabled without developer intervention. Some explicitly enabled via enablePlugins.

Alright, enough talk. Let us imagine such a library - silverfish, you are writing for your team. It will have many plugins s to set the standard for all projects managed by your team. Let us delve into only three of the many plugins.

• CompilerOptionsPlugin: Plugin that configures the host project with a standard set of Scala compiler options
• CreateScalafmtCfgFilePlugin: Plugin that drops a .scalafmt.conf file with a standard set of format options at the root of the host project
• CreateScalafixCfgFilePlugin: Plugin that drops a scalafix config file with a standard set of linting options at the root of the host project

The aforementioned set of Plugin s and others in silverfish serve all other projects. But not the code in silverfish? Ain’t fair. Let us see how to make silverfish serve itself and others. In other words, you preach what you follow yourself.

silverfish
├── build.sbt
├── src/main/scala/silverfish
    ├── CompilerOptionsPlugin
    ├── CreateScalafmtCfgFilePlugin
    ├── CreateScalafixCfgFilePlugin
    ├── ...
├── project/
    ├── plugins.sbt
    ├── ➚CompilerOptionsPlugin
    ├── ➚CreateScalafmtCfgFilePlugin
    ├── ➚CreateScalafixCfgFilePlugin
    ├── build.properties

By creating symlinks to the desired plugins from the src directory in the project directory, we are dogfooding silverfish to the same standard that applies to other projects. Tell me you love¹ SBT!

Cliffhanger

I couldn’t resist telling you this nifty thing in SBT. I will close out next time. Or at least I plan to. As mentioned before, I will discuss some tidbits and a few more good words about SBT.