While I understand why it would be cool for this to be supported without any extra steps, it will mean that all users have to pull in extra dependencies for something that they might not be using.

For a library this can be easily solved by making the dependency an optional peer, but for CLIs that's not as easy.

There's also the argument of "where does it stop?" What would jsonc, json5, and toml support?

I wonder if it would be worth seeing if it might be better to encourage (and support, if not already) passing content in via pipes, and if that turns out to be straightforward go with that rather than this

I.e js-yaml provides a CLI for converting to json, so I wouldn't be surprised if right now you can do something like npx js-yaml path/to/schema.yml | npx json-schema-to-typescript -

@G-Rath That would be cleaner for sure. But because JSON Schemas can reference other schemas, and because we already support .yaml-backed references (https://github.com/APIDevTools/json-schema-ref-parser/tree/main/lib/parsers), I see supporting .yaml for root schemas as more about completeness. In theory if there was a way to make .yaml parsing/pre-processing pluggable all the way through, that would be nicer for sure!

@bcherny fwiw while I've never used it like this myself, npx and co let you pass multiple packages which get installed in the same temp context so my understanding is you should be able to do something like npx -p js-yaml -p json-schema-to-typescript -- json-schema-to-typescript path/to/schema.yml

However, since js-yaml is already a dependency of json-schema-ref-parser, using it directly seems fine to me

Looks good! Please rebase to fix the merge conflict, then I'll merge this.

Thanks for the contribution! Will include this in the next release, next week.