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
foo, then probably you want some code that gets the values associated with the key
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.10 or a later version, add the following dependency to your
libraryDependencies += "com.github.pureconfig" %% "pureconfig" % "0.9.1"
For Scala 2.10 you need also the Macro Paradise plugin:
libraryDependencies ++= Seq( "com.github.pureconfig" %% "pureconfig" % "0.9.1", compilerPlugin("org.scalamacros" % "paradise" % "2.0.1" cross CrossVersion.patch) )
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, first import the library and define data types and a case class to hold the configuration:
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] // res3: Either[pureconfig.error.ConfigReaderFailures,MyClass] = Right(MyClass(true,Port(8080),AdtB(1),List(1.0, 0.2),Map(key -> value),None))
loadConfig methods defer to Typesafe Config's
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