Batch mode for generating interfaces for several JSON-schemas at once

[bcherny]

To avoid generating the same interface twice.

#15 (comment)

[erykpiast]

So how the API may look like? json2ts -i *.json -o ???. Should we allow to specify some kind of renaming pattern (like sed syntax) or just concatenate all interfaces to one ts file when output file is specified and create [orig_name_wo_extension].d.ts files in case it isn't?

[bcherny]

Glob syntax sounds good to me.

I would separate the work into 2 parts:

• Part 1 (easy) - each input file maps to an output file (user can take care of concating), no optimization (TS takes care of type merging, so duplicates are fine)
• Part 2 (harder) - each input file maps to an output file, common types are pulled out into a common file to avoid duplication

[erykpiast]

I like the split 👍.

So, for the first step, results would be like

$ ls *.json
a.json b.json c.json
$ json2ts *.json
$ ls *.d.ts
a.d.ts b.d.ts c.d.ts

no matter if a b or c contain different or equal interfaces, right?

How do we want to prevent people from specifying output file for multiple inputs? Just throw an error?

[bcherny]

Exactly. Error or warning is probably fine. I agree error might be better to keep the API as strong as possible.

[tomaszpeksa]

I expect a little different behavior:
I want to be able to generate multiple *.ts files, one for each defined interface (from each schema). So if some type would be generated many times it would just overwrite the same file.

It seems I'd need to add a function to generator that returns a dictionary like {"file name for type": "file content"} (+ change all declareXxx functions to return an array of strings instead of returning concatenated string, and figure out imports).

The tricky part seems to be generating file names (for SomeType in schema I want to get some-type.model.ts file) so I'd expect user to provide file name generating function.

If that's OK for you I'd start working on a PR providing that.

[bcherny]

@tomekp I'm not convinced that approach is better. Ostensibly if someone has already taken the trouble to put, say, schemas A B and C in JSON-Schema file X and D E and F in JSON-Schema file Y, for their case this is a natural way to modularize and group their schemas. So when we generate TypeScript code from those schemas, it seems natural to put schemas A B and C in X.d.ts and D E and F in Y.d.ts.

If a user wanted to generate 1 file per schema, all they would need to do is feed in one file per schema (a trivial refactoring of their JSON-Schemas).

On the other hand, under your scheme a user couldn't do the opposite, and generate one file containing several schemas by feeding in one file with several schemas.

What do you think?

[bytesnz]

This is a kind of related idea. I was just looking at using this and z-schema for the schemas/typings in one of my projects. I think it is handy to support passing schemas as an array to compile so that $refs can be supported between the schemas given in the array. The functionality would be the same as passing the multiple files to json2ts I would think, apart from outputting a single string.

Edit: Having just looked at the dereferencing, it would require a bit of work as well to support passing other schemas to it in an array