Feature request: Run on glob pattern, output to directory

[icopp]

A simple example of possible syntax:

openapi-typescript "api/*.yml" src/generated

This would run openapi-typescript once for each .yml file in api, and output a file with a matching name (but with .ts extension) to src/generated.

Alternately, this could use something like a -m (for 'match') flag to avoid any backwards compatibility questions:

openapi-typescript -m "api/*.yml" src/generated

Other command line options would be identical to the single-file usage, but it might be useful to also have a -p flag to indicate running in parallel, where the default would be sequential (to play nice with limit-resource environments).

[drwpow]

Thanks for the suggestion! You know, I thought of this, but the main reason I didn’t implement this was I’d be scared that in auto-naming everything as you suggested, someone would ask for a different way to name the output files, and it would just be a pain.

How do you feel about the current Generating multiple schemas section of the README? Would you suggest an alternate approach? I’d like to give people as many options as possible without locking them into a restriction of this library.

[icopp]

Doing it in that style rapidly becomes pretty clunky as you accumulate multiple schema files (as you pretty rapidly can if you're trying to make specific bits of documentation on a big project for multiple external integrations), which is why I made the request to do it in a more integrated way.

[drwpow]

That‘s fair. I think it‘s something we can probably support, with the given restriction that renaming simply isn‘t allowed; filenames and folders will be carried over exactly 1:1. And for anything else, using the Node API is recommended.

[benkroeger]

I'm using a shell script for generating from multiple schemas (also prepending with some eslint rules)

#!/bin/sh
MYPWD=${PWD}
PACKAGE_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )/.." &> /dev/null && pwd )"

cd $PACKAGE_DIR

for spec_file in openapi-specs/*.yaml
do
  file_name="${spec_file##*/}"
  api_name="${file_name%.*}"
  typescript_file="src/apigee-service/@generated-types/${api_name}.d.ts"

  # `openapi-typescript` generates interface names in all lowercase - which doesn't comply with the project's lint rules
  echo "/* eslint-disable @typescript-eslint/naming-convention */\n" > $typescript_file

  npx openapi-typescript $spec_file \
  --prettier-config prettier.config.js \
  >> $typescript_file
done

cd $MYPWD

[sharmarajdaksh]

Hey @drwpow, I might be able to work on this, if nobody else is already working on it.
Also, on globs, could I use node-glob instead of custom implementing that functionality?

[drwpow]

@sharmarajdaksh sure! Here’s what I’d propose:

npx openapi-typescript "src/**/*.yaml" -o src/generated

I propose keeping the same syntax: first (unnamed) input parameter could be a file or glob (I believe glob will still work on a specific filepath). And we still require the output (--output / -o) option still, only it may be a directory now, too.

And let’s throw errors to be helpful:

• Throw error if input is a glob but output is an existing file (i.e. a directory couldn’t be created)
• Vice-versa: throw error if input is not a glob (single file) and output is a directory
• Throw error if input is a remote URL glob (e.g. don’t support https://mysite.com/v1/*.yaml)

This should be backwards-compatible and somewhat intuitive for users (personal opinion: I find CLI tools with different output flags for a file vs a directory to be cumbersome, especially since you can’t use both at the same time; so why not combine them?).

---

Last suggestion: I’m slightly partial to tiny-glob over glob, especially for simple usecases like this.

---

Hopefully that’s not too much direction! I just know there are probably a hundred ways one could implement this and I wanted to make implementation easier.

⚠️ You might want to wait until #602 is merged, as that does make a few changes to how files are loaded (for the better). But to simplify, I believe the glob behavior should be CLI only and should not be integrated into the Node API.

[sharmarajdaksh]

@drwpow yeah, I looked through the code, and I agree that the glob behavior should be CLI-only, without impact on the Node API.
The rest of your suggestions look good. I hadn't come across tiny-glob before, and yes it might be a better option for this use case.
I'll start on this feature then, thanks!

[sharmarajdaksh]

@drwpow now that this feature is added in the main branch, should I also raise a PR updating the project README to mention glob support. I think this feature might have made the example using npm-run-all reduntant as well, so we could remove that (maybe?).

P.S. - If I should raise this in a seperate issue, let me know.

[drwpow]

Merged! Thanks again.

[drwpow]

@sharmarajdaksh Sorry, I missed this. I’m going to do a release tonight, so I can update the README myself. But I’d love a PR if there’s anything you’d like to change or reword (will tag you when it’s up).