PureConfig is a Scala library for loading configuration files. It reads Typesafe Config configurations written in HOCON, Java
.properties, or JSON to native Scala classes in a boilerplate-free way. Sealed traits, case classes, collections, optional values, and many other types are all supported out-of-the-box. Users also have many ways to add support for custom types or customize existing ones.
Click on the demo gif below to see how PureConfig effortlessly translates your configuration files to well-typed objects without error-prone boilerplate.
Loading configurations has always been a tedious and error-prone procedure. A common way to do it consists in writing code to deserialize each fields of the configuration. The more fields there are, the more code must be written (and tested and maintained...) and this must be replicated for each project.
This kind of code is boilerplate because most of the times the code can be automatically generated by the compiler based on what must be loaded. For instance, if you are going to load an
Int for a field named
foo, then probably you want some code that gets the values associated with the key
foo in the configuration and assigns it to the proper field after converting it to
The goal of this library is to create at compile-time the boilerplate necessary to load a configuration of a certain type. In other words, you define what to load and PureConfig provides how to load it.
To use PureConfig in an existing SBT project with Scala 2.11 or a later version, add the following dependency to your
libraryDependencies += "com.github.pureconfig" %% "pureconfig" % "0.11.0"
For a full example of
build.sbt you can have a look at this build.sbt.
Earlier versions of Scala had bugs which can cause subtle compile-time problems in PureConfig. As a result we recommend only using the latest Scala versions within the minor series.
In your code, import
pureconfig.generic.auto and define data types and a case class to hold the configuration:
import pureconfig.generic.auto._ sealed trait MyAdt case class AdtA(a: String) extends MyAdt case class AdtB(b: Int) extends MyAdt final case class Port(value: Int) extends AnyVal case class MyClass( boolean: Boolean, port: Port, adt: MyAdt, list: List[Double], map: Map[String, String], option: Option[String])
Second, define an
application.conf file like this and add it as a resource file of your application (with SBT, they are usually placed in
Finally, load the configuration:
pureconfig.loadConfig[MyClass] // res0: pureconfig.ConfigReader.Result[MyClass] = Right(MyClass(true,Port(8080),AdtB(1),List(1.0, 0.2),Map(key -> value),None))
ConfigReader.Result[MyClass] is just an alias for
Either[ConfigReaderFailures, MyClass], so you can handle it just like you would handle an
loadConfig methods defer to Typesafe Config's
ConfigFactory to select where to load the config files from. Typesafe Config has well-documented rules for configuration loading which we'll not repeat. Please see Typesafe Config's documentation for a full telling of the subtleties.
Alternatively, PureConfig also provides a
loadConfigFromFiles method that builds a configuration from an explicit list of files. Files earlier in the list have greater precedence than later ones. Each file can include a partial configuration as long as the whole list produces a complete configuration. For an example, see the test of
Because PureConfig uses Typesafe Config to load configurations, it supports reading files in HOCON, JSON, and Java
.properties formats. HOCON is a superset of both JSON and
.properties that is highly recommended. As an added bonus it supports advanced features like variable substitution and file sourcing.
Please see the full PureConfig documentation for more information.
PureConfig is a free library developed by several people around the world. Contributions are welcomed and encouraged. If you want to contribute, we suggest to have a look at the available issues and to talk with us on the PureConfig Gitter channel.
If you'd like to add support for types which are not part of the standard Java or Scala libraries, please consider submitting a pull request to create a module. Pull Request #108 created a very simple module. It should provide a good template for the pieces you'll need to add.
The steps to create a new module, called
- Define a new project in the root
build.sbt. There are other examples near the top of the file;
- Create a new
- Add a
modules/nexttopmod/build.sbtdefining the module's name and special dependencies;
- Implement converters. Typically they're in a
- Test the converters. Usually tests would be in
- Optionally explain a little bit about how it works in