Why replace Typesafe Config on JVM?

[jokade]

A somewhat provocative question, but: why do you implement a replacement for Typesafe Config on JVM? Although it's nice being able to add a single dependency for configuration to a cross project, it's not really much effort to add Typesafe config and shocon separately to JVM and JS projects, respectively.

I'm asking because it's quite easy to collect all reference.conf files at compile time for Scala.js using an sbt plugin, but duplicating Typesafe configs elaborate strategy for runtime loading from the classpath seems like an unnecessary effort?

Edit: you could actually provide a dummy shocon package for JVM that simply depends on Typesafe Config; that way one would only need to add the shocon package to the cross project...

[evacchi]

the point is not to implement a replacement for Typesafe Config on the JVM, but to provide a an implementation that cross-compiles for the Scala Ecosystem.

Most Scala Config libraries act as a thin wrapper over the Java source code, with a Scala-idiomatic API. This project is a full Scala implementation with a Scala-idiomatic API, that happens to provide a Java-compatible shim (which I would happily drop, to be fair).

Personally, I am also open to suggestions to improve the situation of the merge/load semantics. I believe we do not probably need to be 100% compatible with the original implementation :)

[andreaTP]

just to add that there are few semantics difference in between shocon and TypesafeConfig, and you are free to choose what to import in JVM projects

[ryantheleach]

Are the semantic differences spec breaking or only in disambiguous cases?

[andreaTP]

on API level there are things that are totally unavailable on JS (like load from File).
moreover you can observe different behaving with numbers due to Scala.JS itself

[ryantheleach]

My question was largely related to running both on the JVM.

@jokade One advantage of having the ability to run it on the JVM though is simplified unit testing of differences that might arrive, comparing it to the reference implementation.