feat(catalog-client): Support generating a front end client based on an OpenAPI spec#17470
Conversation
Changed Packages
|
|
@freben @taras I was able to get a custom generator set up from That being said, I have 2 asks,
|
|
@sennyeya, awesome work on this. Thank you for pushing it forward.
I'm not sure, maybe @freben has a better idea.
Just a heads up, I did look at them previously. One of the challenge with those libraries is that their maintainers don't have much time. I opened a few issues a year ago karlvr/openapi-generator-plus-generators#32 and karlvr/openapi-generator-plus-generators#33. We could add eslint ignore, but just a heads up. |
|
@taras Thanks!
This was something that I was trying to hit an in between state with, the CatalogClient currently handles different endpoints separately (see the
Similar to above, I kept the serializer class from their implementation as an easier bridge from their typescript client, we can definitely remove (see
Yeah, that was one of my concerns, that library seems to have just 1 or 2 maintainers vs |
Uffizzi Ephemeral Environment
|
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
|
This PR has been automatically marked as stale because it has not had recent activity from the author. It will be closed if no further activity occurs. If the PR was closed and you want it re-opened, let us know and we'll re-open the PR so that you can continue the contribution! |
|
Did a little more investigation on the generated types and support, the I looked into |
|
Sorry I haven't reviewed yet - but the changesets are missing! |
|
@freben Added! |
There was a problem hiding this comment.
Would it be possible to have this injected or runtime or smth like that instead? Be nice to not have any new files in the repo root
There was a problem hiding this comment.
I was able to remove this one, however there will probably need to be one in packages/repo-tools. It could be injected at runtime, but it serves as a version lock file that can hold additional config (we're not using that yet, but could in future).
Uffizzi Ephemeral Environment - Virtual ClusterYour cluster
Access the |
Signed-off-by: Aramis Sennyey <sennyeya@amazon.com> Signed-off-by: Aramis Sennyey <sennyeyaramis@gmail.com> Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
|
Uffizzi Cluster |
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Signed-off-by: Aramis Sennyey <aramiss@spotify.com>
Rugvip
left a comment
There was a problem hiding this comment.
NIce! 😁
I think we're good to ship this and keep iterating. In particular figuring out the error responses, I agree defaulting to @backstage/errors would be nice, as well as cleaning up the lint rules and avoid the extra dep.
| : {}; | ||
| const response = await this.fetchApi.fetch(url, { method, headers }); | ||
|
|
||
| private async requestIgnored(response: Response): Promise<void> { |
There was a problem hiding this comment.
I think we could tweak the naming of these now that they're not executing the request and just handling the response. Feeling we can leave that for a followup though
| 'unused-imports/no-unused-imports': 'error', | ||
| 'unused-imports/no-unused-vars': [ |
There was a problem hiding this comment.
Hold up, why are these added here? @typescript-eslint is what we use for unused vars. In general I feel there's really no point in enabling any additional rules for generated code?
There was a problem hiding this comment.
Ah, yeah let me take another look at this. This is the library I've used in the past. Without this, we're getting a tsc error for unused variables if we keep this as is. The @typescript-eslint rule adds the check, but the unused-imports plugin adds an autofix rule, unless something changed in @typescript-eslint recently?
There was a problem hiding this comment.
Ah so it trims away things to make tsc work? Makes sense then, let's ![]()
|
Thank you for contributing to Backstage! The changes in this pull request will be part of the |
|
Amazing work @sennyeya thank you 🙏 |
Hey, I just made a Pull Request!
Summary
Another step for #2566. There's a lot of code with this PR, the basic idea is to support using
openapi-generatorwith some overrides to create a "closer to the spec" API client.What's in this PR?
The primary work is in the
packages/repo-tools/templateswhich is a set of overrides to the Mustache templates thatopenapi-generator'stypescriptgenerator uses under the hood. There are some unfortunate requirements there, namely the.model.tsand.client.ts. My goal here was to reuse the upstream template as much as possible.I also adjusted the current CatalogClient to use the generated code under the hood instead of creating URLs and requests. The
packages/catalog-client/src/generatedfolder is from the custom generator.✔️ Checklist
Signed-off-byline in the message. (more info)