Elm.buildFile returns a pair (String, String)
where the first element is the name of an Elm file
and the second element is the content for that file,
containing type and JSON codec definitions.

To avoid circular references, Elm.buildFile can generate
a single file for a list of declarations.

If you want to use any of the JSON encoders or decoders generated by the project
you need to do the following:

Your Elm project must include the
NoRedInk/elm-decode-pipeline dependency

We assume any non-primitive type in your ADT will be
generated by Bridges in the same module as the current ADT,
to be able to define the right imports for them.

If your ADT contains a sum type,
the generated json must distinguish between alternatives
using a field named type that encodes
the name of the product instance as a String.
If you use Circe,
see this link.

Working with Refined types

If you are interested in this library
you are most likely using Refined.

We have provided a default encoder for refined types. It will defaults
to the basic type associated with the refined type. For example:

For Int Refined Greater[W.6.T] we treat the type as an Int

For String Refined Size[ClosedOpen[W.1.T, W.100.T]] we treat the type as a String

etc

This should cover most (if not all) use cases of refined types when converting to other languages.
You can still override the default encoder with your own higher-precedence encoder.

You can see an example of this in tests for class ClassWithRefinedType.