Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand that change: this declaration is identical to the one in the core library. Maybe you can explain why it's required to add a default generic value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simonbrunel first of all, let me say I don't have much experience on TS therefore I cannot explain you well why that's needed.
We had the same issue on annotation and zoom and I raise the issue on Slack Chart.js dev channel. @SebastiaanSafeguard had a look and he found this solution (that's working).
The bug seems to be introduced since Chartjs 4.1.0 by PR chartjs/Chart.js#10963.
It seems it needs to have the same type for interfaces merging. It wasn't possible to change only Chart.js without breaking other stuff.
I know that's not a good explanation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not entirely sure why this would be a breaking change exactly? I believe the only thing this does is help out the typescript compiler to see that multiple plugins are in fact using the same types.
Changing the declaration in the core library does not work, most likely because TSC needs to merge the different declarations and it is starting with core as ground truth.
What I believe is happening is that it tries to merge the declarations, and it has 3 (or more) type variables: TType, TType and TType. It only manages to merge two of the three(+). Even though they are meant to all be the same. As given by the error:
It thinks that
PluginOptionsByType<TType, TType>
is a thing here, even though there is only a single generic type.Adding a default type seems to help the compiler to figure out that they can actually all be the same (since the default type can be a type for all type variables) thus allowing that the declarations are merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your replies.
Because we are changing the declaration merging and this may impact people who have a working integration.
Is there an easy way to reproduce this issue? Can someone share a repo with minimal setup that shows this error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it would be better to investigate if that PR didn't introduce wrong code instead of spreading the default generic in all plugins (and beyond). If it's indeed the cause, maybe @dangreen could try to explain why his change have so much impact and maybe figure out if there is a better way to fix the issue mentioned in chartjs/Chart.js#10963.
To me, the current PR seems to introduce a bad workaround that I'm worry will backfire later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chartjs/chartjs-plugin-annotation#854 (comment)
In the issue there is a zip file with a project where you can reproduce the issue with zoom and annotation plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dangreen this is the issue that I raised some weeks ago in Slack and you had a look. New info is that the bug seems to be introduced by chartjs/Chart.js#10963, Chart.js version 4.1.0.
@simonbrunel for me it's fine ;). I fully agree to find out the best solution even if my poor knowledge in TS cannot help me to contribute too much on that.
Furthermore the PR chartjs/Chart.js#11244 has been approved and merged which fixed the doc, about how to implement the extension adding the default, and therefore I thought this workaround sounded ok!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No? The merging is not changing? Maybe the merged declaration would change, but that is also not the case because the type parameter
TType
is still the same thing.Anyways. Based on some testing I am not sure chartjs/Chart.js#10963 is the culprit. Reverting that in a local install does not fix the problem. There seems to be a difference in the way the types are packaged between 4.0.x and >4.1.x though (the latter has a full types folder in dist), which indicates to me that more changed. But I cannot find when or why.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simonbrunel @SebastiaanSafeguard FYI I have submitted an issue in Chart.js repo because this update is creating another issue. chartjs/Chart.js#11288 therefore I would agree with @simonbrunel that something is wrong on TS definitions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@simonbrunel @SebastiaanSafeguard I found why we have this issue. See chartjs/Chart.js#11288 (comment)