Skip to content

fix(typings): Add comment property #72

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Jul 2, 2020
Merged

fix(typings): Add comment property #72

merged 2 commits into from
Jul 2, 2020

Conversation

ffflorian
Copy link
Contributor

@ffflorian ffflorian commented Jun 30, 2020 •
edited
Loading

After #71 was merged, the typings were not updated.

cc @sparticvs

@sparticvs
Copy link
Contributor

Thanks @ffflorian. New to typescript, good to know that is needed.

patrickhulce
patrickhulce requested changes Jul 2, 2020
View reviewed changes
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

thanks very much @ffflorian!

I think we should augment the decode return types with this though since encode won't do anything with the comments

maybe just & {comment?: string} onto the decode return type declarations?

@ffflorian
Copy link
Contributor Author

@patrickhulce good idea. But the question is: does encode accept the comments option? If yes I think it should stay like this.

@patrickhulce
Copy link
Collaborator

does encode accept the comments option? If yes I think it should stay like this.

Depends on your definition of "accept" :)

It won't throw an error, but it won't do anything at all with them either. Their existence of comments in the typedef of encode in this PR suggests to a consumer that it's an optional parameter that might affect the behavior of encode (i.e. that encode has the ability to encode comments into the output buffer when it doesn't). comments support is exclusive to decode. Does that make sense?

@ffflorian
Copy link
Contributor Author

It won't throw an error, but it won't do anything at all with them either. Their existence of comments in the typedef of encode in this PR suggests to a consumer that it's an optional parameter that might affect the behavior of encode (i.e. that encode has the ability to encode comments into the output buffer when it doesn't). comments support is exclusive to decode. Does that make sense?

Yes, that totally makes sense! I'll update my PR later :)

@ffflorian
Copy link
Contributor Author

@patrickhulce PR updated :)

patrickhulce
patrickhulce approved these changes Jul 2, 2020
View reviewed changes
Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

oof, I'm so sorry @ffflorian but I had a typo in my original suggestion.

with these suggestions it looks great though! :)

@patrickhulce patrickhulce merged commit ca27601 into jpeg-js:master Jul 2, 2020
@ffflorian ffflorian deleted the patch-1 branch August 26, 2020 07:46
zed-0xff pushed a commit to zed-0xff/jpeg-js that referenced this pull request Feb 24, 2023
@ffflorian
fix(types): add comments property to decode output (jpeg-js#72)
422ae38
@ASISBusiness ASISBusiness mentioned this pull request Aug 16, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@patrickhulce patrickhulce patrickhulce approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@ffflorian @sparticvs @patrickhulce