Skip to content

fix(typings): Add comment property#72

Merged
patrickhulce merged 2 commits intojpeg-js:masterfrom
ffflorian:patch-1
Jul 2, 2020
Merged

fix(typings): Add comment property#72
patrickhulce merged 2 commits intojpeg-js:masterfrom
ffflorian:patch-1

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

sparticvs commented Jul 2, 2020

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

ffflorian commented Jul 2, 2020

@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

patrickhulce commented Jul 2, 2020

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

ffflorian commented Jul 2, 2020

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

ffflorian commented Jul 2, 2020

@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