search

krg7880 / json-schema-generator

Generates draft v4 schema from a local file or a remote JSON url.
MIT License
174 stars 53 forks source link

export the generator #8

Closed marbemac closed 8 years ago

marbemac commented 9 years ago

var generator = require('json-schema-generator')

For whatever reason, in my setup (webpack, es6), this package doesn't work unless it's exported. Is there any reason not to export it?

krg7880 commented 9 years ago

Thanks for the updates. No reason not to export the module. Why relax the constraints? If you feed the module a JSON doc and a value exists for a given key, shouldn't we assume it's required?

marbemac commented 9 years ago

Ah I completely forgot that additional commits would be tacked onto this PR. That was meant as a change to my fork only, as it fits my specific project requirements. Feel free to cherry pick that first commit, or just add it yourself!

krg7880 commented 9 years ago

Ah! Gotcha! Thanks for pointing out the export issue, however.

nickyout commented 9 years ago

Personally I really like that it applies as many constraints as it can guess. It's easier to remove constraints than to (look up the documentation on json-schema and) add them yourself.

I'd personally suggest adding an optional options object parameter to the single function to pass any specific preferences like this. Which, when absent, defaults to the current behavior.

Still, +1 for module.exports =

It's already been added in the meantime. Never mind.

krg7880 commented 9 years ago

Yeah, it's done :-) Regarding constraints, perhaps it's useful to use some sort of configuration or CLI options to relax the constraints? Any thoughts?

nickyout commented 9 years ago

Some new CLI option(s) will be translated into an options object, which will then be fed to the core lib.

The more interesting question imo is what granularity of options to offer. The most extreme version is offering every option in the spec and give a way to specify several scopes within the source JSON to apply such a set of options to. Probably a complete overkill at this point.

A much easier alternative is a CLI option like --style=<const>, where const gives a way to convey your intent: lax for as free as possible, strict for as constrained as possible, or perhaps verbose for as many schema options as possible (for the sake of seeing which options you have, and removing the ones you don't want).

Depending on this granularity, you can choose to provide an --options=<path> to a json describing your options (in case they are many), or just keep it to a few generic options that are covered by a few extra CLI options.

I'd suggest starting with the --style option (or a similar degree of simplicity), and make it more granular when you actually see that adding it would resolve a problem in practice. At that point, the original --style option can become an alias for certain sets of the more specific options.

What options would you like to be able to use? I remember wanting to have something like verbose.