Skip to content

[incomplete] Allow external references #433

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

Closed
wants to merge 18 commits into from

Conversation

chris-armstrong
Copy link

I'm opening this PR to solicit feedback

At the moment, openapi-typescript-codegen can only resolve $ref references to components in the same file. I've begun working on support for resolving external $ref references (i.e. where the openapi file has '$ref' entries that refer to other files relative to it on the filesystem).

This makes it easier to split a large openapi.yml into multiple files. It also helps to bring the tool closer in line with the JSON Reference spec, which is allowed by the OpenAPI 3.0 specification.

I've deliberately neglected URL references other than those on the current filesystem for now, but there's no reason this couldn't be added (perhaps behind a flag for those who don't want it making HTTP calls?)

This PR isn't complete, as in not all cases where $ref is allowed have been updated and tested, and it has only been done for the 3.0 side.

Could I get some feedback as to whether this PR would be accepted if continued along its current lines, or if it will require some more significant changes to the way it is structured? I'd love to be able to get this functionality into the main codebase.

@lgtm-com
Copy link

lgtm-com bot commented Nov 19, 2020

This pull request introduces 2 alerts when merging deff23e into bb78808 - view on LGTM.com

new alerts:

  • 1 for Syntax error
  • 1 for Template syntax in string literal

@codecov
Copy link

codecov bot commented Nov 19, 2020

Codecov Report

Merging #433 (bc13384) into master (5559a15) will decrease coverage by 3.37%.
The diff coverage is 66.87%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #433      +/-   ##
==========================================
- Coverage   93.49%   90.12%   -3.38%     
==========================================
  Files         106      106              
  Lines        1261     1337      +76     
  Branches      219      236      +17     
==========================================
+ Hits         1179     1205      +26     
- Misses         82      132      +50     
Impacted Files Coverage Δ
src/openApi/v2/parser/getRef.ts 44.00% <39.13%> (-46.00%) ⬇️
src/openApi/v3/parser/getOperationResponse.ts 87.71% <53.33%> (-12.29%) ⬇️
src/utils/refs.ts 55.88% <55.88%> (ø)
src/openApi/v3/parser/getModelProperties.ts 70.83% <58.82%> (-29.17%) ⬇️
src/openApi/v3/parser/getModel.ts 92.85% <80.00%> (-7.15%) ⬇️
src/index.ts 79.16% <100.00%> (+1.89%) ⬆️
src/openApi/v3/index.ts 100.00% <100.00%> (ø)
src/openApi/v3/parser/getModelComposition.ts 100.00% <100.00%> (ø)
src/openApi/v3/parser/getModels.ts 100.00% <100.00%> (ø)
src/openApi/v3/parser/getOperation.ts 100.00% <100.00%> (ø)
... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5559a15...bc13384. Read the comment docs.

@ferdikoomen
Copy link
Owner

@chris-armstrong Interesting Chris! I'm working on some core rewrites, the resolving / bundeling logic is indeed nice to add.

@chris-armstrong
Copy link
Author

chris-armstrong commented Nov 26, 2020

@chris-armstrong Interesting Chris! I'm working on some core rewrites, the resolving / bundeling logic is indeed nice to add.

Great! I'll continue working on it to clean it up and get it tested properly and add it back to the v2 schema parsing / generation. It might take me a while but I'll update this when its ready.

@ibolmo
Copy link

ibolmo commented Jan 15, 2021

@ferdikoomen this is something I need. You had mentioned some core rewrites. Would you say that is blocking this PR from moving forward?

@chris-armstrong
Copy link
Author

Instead of continuing development of this one, which was becoming extensive, I've found a library that achieves the same effect and can be integrated with minimal code change, so I've opened #573 instead to achieve the same outcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants