Feature.Pack (Json.Profile ???)

[andyglow]

h1. Problem There are many scala libraries exists that solves parse/format problem for different scala types. Not all of them follow the same standard, though. For example:

• ujson libs treat scala.Option as json-array (by default)
• some other use json.null for scala.None, whereas others just omit the field (when it comes to case class field >> json-object field
• some libs may have support for scala.Either to json codecs, when the others haven't
• some libs support recursive types, some others don't
• discriminator field for sealed traits is treated differently

As of now scala-jsonschema has a single perspective on

• a feature-set
• and on how scala type is converted into json. Which leads to desynchronization. What derived schema shows basically not always coincides with what codec produces.

h1. Idea scala-jsonschema should be flexible on this and provide extensible api so lib developer and/or extension developer may instruct it about what features supported, implementation specific of certain features and so on.

case class FeaturePack( // JsonProfile?
  `feature-xxx-enabled`: Boolean,
  `feature-yyy-details`: FeatureYYYDetails,
  ...
)

The existence of instance of this class in implicit scope of macro call should affect the way derivation logic process certain types.

[andyglow]

linking #220