Allow using non-standard formats about fluent-json-schema

[aboutlo]

I don't like to add a customFormat method but following @jnv idea we could pass an array e.g. extraFormats as option something like that:

FluentSchema({extraFormats: ['my-custom-format']}).asString().format('my-custom-format')

In the JSDoc of the format method, we could add the above example

Then in the format implementation, we can merge FORMATS and extraFormats to check that the format is supported.

Name wise I don't like too much extraFormats or customFormats, but I think it's misleading using formats someone could think we are overriding the default FORMATS.

Test wise we have do double check that in a nested schema the extraFormats are propagated to the children. It should I did a refactoring in the 0.3.0 version so it should. 🤞

[jnv]

Thanks @aboutlo, support for raw JSON injection is quite a good compromise.

[aboutlo]

I need to dig into the specification but it doesn't seem a good idea to add a flavor. Maybe I'm too careful. Let me think more about that. @mcollina thoughts?

[mcollina]

IMHO it’s a bad idea, but a lot of people ask/need this. Providing some sort of escape hatch to add this would be good to accept as a PR.

[jnv]

The spec says:

Implementations MAY add custom format attributes. Save for agreement between parties, schema authors SHALL NOT expect a peer implementation to support this keyword and/or custom format attributes.

In our case this is useful for reducing boilerplate in schemas within a shared domain. It is more readable to specify a semantic format rather than to repeat pattern everywhere.

I will be happy to submit a MR if you specify how the API should look.
Beside an additional method, perhaps one could pass an array of custom supported formats to FluentSchema(), though that could cause a lot of duplication or mistakes during authoring.

[aboutlo]

Moved the discussion here: #55