-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/dynamite/header type resolver #1024
Conversation
packages/dynamite/dynamite_end_to_end_test/lib/headers.openapi.json
Outdated
Show resolved
Hide resolved
65efb1a
to
59574e7
Compare
I hope that we can sort the generated classes in the future to avoid such diffs. |
Maybe we should then first figure out how to prevent this diff? |
@provokateurin can I get a froce merge? The generation check for dynamite_e2e timed out and I already fix this in #1014 (which depends on this PR being merged) EDIT: we might need to find a different solution as the nextcloud tests didn't even run :/ |
Signed-off-by: Nikolas Rimikis <[email protected]>
Signed-off-by: Nikolas Rimikis <[email protected]>
59574e7
to
3b6cbd9
Compare
packages/dynamite/dynamite/lib/src/builder/generate_schemas.dart
Outdated
Show resolved
Hide resolved
Signed-off-by: Nikolas Rimikis <[email protected]>
This was a funny bug :)
We use generator functions where possible in dynamite for performance reasons. The problem is that they only get invoked lazily (when iterating). This means that they where only executed in the
addAll
code segment. BecausegenerateImports
was called before adding the code generated bygenerateClients
we where not taking the resolved types from these methods into account.an empty operationId caused our code to fail (fb01f7e)
We didn't hit it but we where calling
output.add
for the TypeDefs before we added the imports to the output meaning that we could potentially have code before the imports.