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

fix(typings): Add comment property #72

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

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.

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 :)

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! :)

index.d.ts Outdated Show resolved Hide resolved
index.d.ts Outdated Show resolved Hide resolved
@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
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.

None yet

3 participants