sbt

An AutoPlugin defines a group of settings and the conditions where the settings are automatically added to a build (called "activation"). The requires and trigger methods together define the conditions, and a method like projectSettings defines the settings to add.

Steps for plugin authors:

1. Determine if the AutoPlugin should automatically be activated when all requirements are met, or should be opt-in.
2. Determine the AutoPlugins that, when present (or absent), act as the requirements for the AutoPlugin.
3. Determine the settings/configurations to that the AutoPlugin injects when activated.
4. Determine the keys and other names to be automatically imported to *.sbt scripts.

For example, the following will automatically add the settings in projectSettings to a project that has both the Web and Javascript plugins enabled.

object MyPlugin extends sbt.AutoPlugin {
 override def requires = Web && Javascript
 override def trigger = allRequirements
 override def projectSettings = Seq(...)

 object autoImport {
   lazy val obfuscate = taskKey[Seq[File]]("Obfuscates the source.")
 }
}

Steps for users:

1. Add dependencies on plugins in project/plugins.sbt as usual with addSbtPlugin
2. Add key plugins to projects, which will automatically select the plugin + dependent plugin settings to add for those projects.
3. Exclude plugins, if desired.

For example, given plugins Web and Javascript (perhaps provided by plugins added with addSbtPlugin),

myProject.enablePlugins(Web && Javascript)

will activate MyPlugin defined above and have its settings automatically added. If the user instead defines

myProject.enablePlugins(Web && Javascript).disablePlugins(MyPlugin)

then the MyPlugin settings (and anything that activates only when MyPlugin is activated) will not be added.

An error that occurs when auto-plugins aren't configured properly. It translates the error from the underlying logic system to be targeted at end users.

Uniquely identifies a build by a URI.

Identifies a build.

A concrete settings system that uses sbt.Scope for the scope type.

Identifies an input task. An input task parses input and produces a task to run. It consists of three parts: the scope, the name, and the type of the value produced by an input task associated with this key. The scope is represented by a value of type Scope. The name and the type are represented by a value of type AttributeKey[InputTask[T]]. Instances are constructed using the companion object.

Constructs InputKeys, which are associated with input tasks to define a setting.

Parses input and produces a task to run. Constructed using the companion object.

Identifies a project in the current build context.

Identifies the root project in the current build context.

An expression that matches AutoPlugins.

Indicate whether the project was created organically, synthesized by a plugin, or is a "generic root" project supplied by sbt when a project doesn't exist for file(".").

Uniquely references a project by a URI and a project identifier String.

Identifies a project.

Identifies a project or build.

A fully resolved, unique identifier for a project or build.

Identifies the root project in the specified build.

Specifies the Scope axes that should be used for an operation. true indicates an axis should be used.

An abstraction on top of Settings for build configuration and task definition.

Methods and types related to constructing settings, including keys, scopes, and initializations.

A common type for SettingKey and TaskKey so that both can be used as inputs to tasks.

Select is a type constructor that is used to wrap type S to make a scope component, equivalent of Some in Option.

Identifies a setting. It consists of three parts: the scope, the name, and the type of a value associated with this key. The scope is represented by a value of type Scope. The name and the type are represented by a value of type AttributeKey[T]. Instances are constructed using the companion object.

Constructs SettingKeys, which are associated with a value to define a basic setting.

SlashSyntax implements the slash syntax to scope keys for build.sbt DSL. The implicits are set up such that the order that the scope components must appear in the order of the project axis, the configuration axis, and the task axis. This ordering is the same as the shell syntax.

Identifies a task. It consists of three parts: the scope, the name, and the type of the value computed by a task associated with this key. The scope is represented by a value of type Scope. The name and the type are represented by a value of type AttributeKey[Task[T]]. Instances are constructed using the companion object.

Constructs TaskKeys, which are associated with tasks to define a setting.

A SettingKey, TaskKey or Initialize[Task] that can be converted into an Initialize[Task].

This is a scope component that represents not being scoped by the user, which later could be further scoped automatically by sbt.

Identifies the build for the current context.

Identifies the project for the current context.

The sbt 0.10 style DSL was deprecated in 0.13.13, favouring the use of the '.value' macro.

See https://www.scala-sbt.org/1.x/docs/Migrating-from-sbt-013x.html#Migrating+from+sbt+0.12+style for how to migrate.

Zero is a scope component that represents not scoping. It is a universal fallback component that is strictly weaker than any other values on a scope axis.

An annotation to designate that the annotated entity should not be considered for additional sbt compiler checks. These checks ensure that the DSL is predictable and prevents users from doing dangerous things at the cost of a stricter code structure.