Skip to content
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

Create types from URL #187

Closed
psmyrdek opened this issue Apr 9, 2020 · 4 comments
Closed

Create types from URL #187

psmyrdek opened this issue Apr 9, 2020 · 4 comments

Comments

@psmyrdek
Copy link
Contributor

psmyrdek commented Apr 9, 2020

As far as I see, this library doesn't support creating specs based on the remote resources yet. Reasoning would be that in microservices environment, there are many modules which expose spec on given URL, but not all of them publish it as a package to some internal package registries.

For example, one could imagine the following API:

npx @manifoldco/swagger-to-ts --url https://remote.com/specs.json --output schema.d.ts

Can I try introducing such a PR? How do we feel about such an improvement? How the ideal flow would look like?

@RinatGumarov
Copy link

RinatGumarov commented Apr 9, 2020

It will be useful for me too. Also I shouldn't write it here, but I also want to enum type to be parsed properly.
Upd: Oh.. I found this issue too=)

@drwpow
Copy link
Owner

drwpow commented Apr 10, 2020

@psmyrdek a PR for that would be greatly appreciated!

What about if we just skipped the --url flag altogether, and just accepted it as the main input?

npx @manifoldco/swagger-to-js https://remote.com/specs.json …

And we’d just parse that first param: if it starts with a remote protocol fetch it; otherwise assume it’s a local file. I think that’d keep the API simpler. And it’d save us from having to conditionally require that first param or not.

It’s not exactly outlined, but a goal of this project is to keep dependencies as few as possible for performance. So if we could get away with using Node’s core http/https modules for fetching that’d be ideal.

@drwpow
Copy link
Owner

drwpow commented Apr 10, 2020

Also I shouldn't write it here, but I also want to enum type to be parsed properly.

@RinatGumarov You sure shouldn’t write a different issue in an unrelated ticket! 😛 Feel free to open another issue with a reproduction of your issue and the version you’re using please 🙇

@psmyrdek
Copy link
Contributor Author

@DangoDev Sounds good - will prepare a PR as quickly as I can.

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

No branches or pull requests

3 participants