--verbose flag for Orval generation

[ignatzami]

I'm presently trying to generate a schema for a very large OpenAPI specification (MSGraph) and I'd love the ability to have the tool report progress as it goes.

As it stands, I've been staring at a terminal window for minutes and wondering if the process is still active, is it choking, is progress being made? Given that even with a smaller spec (the petstore.yaml) output isn't exactly blazing fast I feel that some user feedback during conversion would be very helpful.

[ignatzami]

I successfully generated a piece of the Graph API (https://github.com/microsoftgraph/msgraph-sdk-powershell/blob/dev/openApiDocs/v1.0/Groups.yml)

Even this smaller (thought still substantial) spec took over 13 minutes to process.

2025-01-13 11:27:12.580
🍻 Start orval v7.4.0 - A swagger client generator for typescript
Running afterAllFilesWrite hook...
🎉 ms-graph - Your OpenAPI spec has been converted into ready to use orval!
2025-01-13 11:40:06.429

[AllieJonsson]

While I think logs would be great, in the meantime I think disabling validation will help a lot with reducing time generating:

input: {
  target: '/mySchema.yaml',
  parserOptions: {
    validate: false,
  },
}

[madskchristensen]

I just tried this option on a project, where I have type generation times of up to 25 minutes. It's now taking ~6 seconds.

Am I correct in assuming that setting validate: false in the parserOptions will simply turn off validating the input file? In my case I'm using a swagger file to generate my types. So by turning this validation off I'm simply telling Orval to trust that the swagger is correctly generated/formatted?

If so am I correct to assume that - as long as I can trust the swagger input - the output will be correct with this validate setting set to false?

[melloware]

@madskchristensen you nailed it!

[madskchristensen]

@melloware Awesome, thanks for the quick response. Sorry for hijacking this issue but...

It would be hugely beneficial if you updated your documentation to reflect what this option does.

I've done a deep-dive into why our type/api generation would be so time consuming, and it lead me down a rabbit hole, where I could conclude that the swagger-parser lib is "at fault".

As part of the target input validation adereference function used (imported from @ApiDevTools/json-schema-ref-parser), which consumes a large amount of time. Due to crawling through every single object/property in the provided target input.

The project I'm working on has quite a few circular dependencies (NestJS) - so that might be the reason, as the implementation of this function also contains a conditional recursive call to itself.

Either way I think your docs could greatly benefit from having an explanation outlining this. In our case we've considered replacing Orval quite a few times, due to the type gen speed causing a sub-optimal developer experience.

Again, thanks for your quick reply. Much appreciated!

[melloware]

I wonder if we should make the default FALSE as well... PR is welcome to update the docs @madskchristensen !

[madskchristensen]

@melloware I wouldn't mind submitting a PR, but I would need more context into how Orval works.

For example, I'm still not entirely sure about the purpose of the validate "step" within Orval.

On our project we just did a spot-test with validate: true and validate: false in the parserOptions. It seems that there is no difference in the generated Orval types and hooks. Which begs the question as to what this option solves. Again, we simply did a few comparisons, so there might be an actual difference.

1. Are you dereferencing the swagger $refs somewhere within Orval - outside the scope of the validate step? And if so - are you using the swagger-parser lib for this?
2. If the purpose of the validate function is simply to validate that the input target conforms to valid openapi 2.x.x/3.x.x - that is at least worthy of putting in the docs. Potentially with your suggestion of having validate: false as the default. Making the time-consuming validation opt-in, for projects where the target input can not be "trusted" to be valid.

[melloware]

as far as dereferencing see these two closed PR's that were rejected: https://github.com/orval-labs/orval/pulls?q=is%3Apr+is%3Aclosed+dereference

[madskchristensen]

Thanks, I'll take a look!