Thinking outside the toolbox

Integrate Scala tools with your workflow with Build Server Protocol

Jane Elizabeth
Build Server Protocol
© Shutterstock / muk woothimanop

Instead of asking developers to learn a new IDE or build tool, is it possible to ship tools that integrate with a preexisting workflow? Scala’s new Build Server Protocol suggests that it is indeed possible.

There’s nothing as irritating as finding a cool tool that is perfect for that programming problem plaguing your code, only to run into support issues. Somehow, these Scala tools aren’t working with your current setup and require an additional editor or IDE or build tool support. Suddenly, a developer needs to master this specific toolchain before they can even get to the good stuff.

Integrating language servers and build tools takes times. This work needs to be duplicated for every new language server – a waste of time for developers. Instead of fixing bugs and improving performance, developers are making sure the toolchain plays nicely with the sandbox.

SEE ALSO: A quick tour of build tools in Scala

Build Server Protocol

With Scala’s Build Server Protocol (BSP), developers can use any IDE or build tool they need without any extra special support. The Build Server Protocol standardizes the protocol for how severs and clients communicate. This means a single Build Sever can communicate with multiple IDEs, which can support build tools with minimal support.

This concept was derived from Microsoft’s Language Server Protocol, which covers language servers and editors. However, the Build Server Protocol specifies endpoints between a language server acting as a client and a build server.

The Build Server Protocol has been designed to support basic language integration in an IDE or editor. It comes with a number of features out of the box. IDEs can find modules defined in a workspace, ask for dependencies, compile, test, run, and get notifications.

Since the BSP facilitates communication between the build tool and the IDE, build tools can send notifications whenever there are changes. There’s no need to manually check on a regular basis if everything is in sync; the build server protocol takes care of that.

Additionally, the BSP prototype allows developers to get compiler diagnostics directly. These diagnostics are the most up-to-date, considering that all the compilation happens there.

SEE ALSO: Countdown to Scala 3 – Dotty confirmed for Scala 3.0

Next steps

As of right now, the Build Server Protocol is still a work in progress. The next steps are focused on increasing use and improving the number of integrations available for developers. The BSP is a language-agnostic protocol that can be modified to support any programming language. The sky’s the limit here.

The BSP is looking for a few good developers to help out; head on over to the scalacenter/bsp Gitter channel for more information. More information about the Build Server Protocol can be found on GitHub and the Scala language blog.

Jane Elizabeth
Jane Elizabeth is an assistant editor for

Inline Feedbacks
View all comments