Serialization key casing changes

[allancalix]

It's fairly common when working with configuration languages to find multiple common casings for keys and it would be nice to handle these configuration details at either export or schema definition layer to make ingesting schemas more uniform.

For example, if defining schemas for two different json configs you would need your .ncl keys to match the casing to export the correct casing on keys:

{
    "nameField": "foobar"
}

{
    "name_field": "foobar"
}

It would be nice to be able to conform to standard nickel conventions regardless of conventions of the target configuration schema. Then at either export time or via metadata you could do something like nickel export --format=toml --rename-keys=kebab-case -f config.ncl.

Either way I'm curious how others work with targeting a variety of configuration formats with different conventions.

A code example of what I'm proposing currently works only for top-level key names.

[yannham]

Hmm, that's a good question. So far I think we've been using the convention of the target tool directly, using the Nickel convention only for internal values (say functions or contracts). I can see why this isn't ideal. One brutal way to do it could be to apply a specific function defined in pure Nickel, that would traverse the configuration, rename the fields on the fly, and re-assemble the configuration. Beside needing to define all the renaming logic in pure Nickel, it's going to be painful. I guess the pro is that it seems possible to do as of today without changing Nickel itself in any way.

Another way could be to use metadata, indeed. On one hand I think we have to be careful to keep metadata in control and avoid feature creeping until it becomes a complex and accidental proper DSL inside Nickel itself. Still, if a feature seems to be really needed for many users, we can consider it. There is a different but related issue about post-processing (#1170). We might play with that idea. Maybe we can consider having a more general export_options metadata which can control several export-related things (format-related, post-processing, casing, etc.), or the export_with propsoed in #1170 could also have the power of processing the field name.