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

feat: respect input format when producing outfile #56

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

adaam2
Copy link

@adaam2 adaam2 commented Sep 13, 2024

This PR adds support for producing outfiles that match the file extension of the input file (for single inputs only). Currently if you have a JSON input file with an overlay, the outfile will always be yaml which is confusing to the user. particularly in the studio.

Additionally, if the single source is a remote file, and a matching file extension (json or yaml) can't be parsed from the URI path, then we now try and fetch the URL and try and parse the body as YAML/JSON.

// Attempts to fetch the remote file and determine the format (yaml / json)
// based on the contents of the file
func (s Source) getRemoteResolvedExtension(input string) InputFileType {
res, err := http.Get(input)
Copy link
Member

@ThomasRooney ThomasRooney Sep 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this works for a lot of cases:

  1. Some remote files are blocked by authentication headers - these are provided alongside the input location.
  2. This getRemoteResolvedExtension(input) is also used with registry URIs.

I think we need to delegate to ResolveDocument which currently lives within the speakeasy repo. It could also probably cache the document to stop unnecessary duplication of calls.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, sounds good. I will do some investigation into this 👍🏻

Aside from this fetching logic to be stripped out and replaced with ResolveDocument, the approach is generally sound?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep; definitely!

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.

2 participants