Release v2.2.1 #563
Release v2.2.1 #563
Conversation
…cate code fragments #506
…ot removable when not initialized by init function
… (accepts KeyboardEvent) #506
…ns of no options are defined, fixes no empty object type #506
…it any, set interval method without window #506
…ze based on given type in method call #506
…orts and for specific parameter type validation #506
There was a problem hiding this comment.
Referencing to #560, I notice that in this commit we changed the M_ from object orientated to array based
This introduces backwards compatibility issues on v2.2.1 for applications depending on the object orientated approach
For now, my suggestion would be to revert changing the M_ from object orientated to array based back to object orientated approach and change @typescript-eslint/no-explicit-any to warning instead of error in eslint to let the build pass
In meanwhile, we can look for alternative object type declaration to suppress the warnings in one of the next releases
As of v2.2.1 upgrading from v2.1.1 to v2.2.1 is not working or would introduce a major upgrade in existing codebases, which makes it more of a major upgrade instead of minor and would require to introduce additional documentation for the upgrading process to end-users
For the maintainability and scalability regarding Materialize I know it's important to end-users to upgrade with less effort as possible without having to fix broken components, propose to revert, WDYT?
| @@ -112,7 +113,7 @@ export class Autocomplete extends Component<AutocompleteOptions> { | |||
|
|
|||
| constructor(el: HTMLInputElement, options: Partial<AutocompleteOptions>) { | |||
| super(el, options, Autocomplete); | |||
| (this.el as any).M_Autocomplete = this; | |||
| this.el['M_Autocomplete'] = this; | |||
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| return (el as any).M_Autocomplete; | ||
| return el['M_Autocomplete']; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| (this.el as any).M_Autocomplete = undefined; | ||
| this.el['M_Autocomplete'] = undefined; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| (this.el as any).M_FloatingActionButton = this; | ||
| this.el['M_FloatingActionButton'] = this; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| return (el as any).M_FloatingActionButton; | ||
| return el['M_FloatingActionButton']; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| return (el as any).M_Toast; | ||
| return el['M_Toast']; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| const toast: Toast = (toastElem as any).M_Toast; | ||
| const toast: Toast = toastElem['M_Toast']; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| (this.el as any).M_Tooltip = this; | ||
| this.el['M_Tooltip'] = this; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| return (el as any).M_Tooltip; | ||
| return el['M_Tooltip']; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
| (this.el as any).M_Tooltip = undefined; | ||
| this.el['M_Tooltip'] = undefined; |
There was a problem hiding this comment.
I think we might need to revert this, since it introduces backwards compatibility issues with applications using the previous object orientated approach, propose to just set it to warnings until we can declare the correct type definition
Proposed changes
Sorry, forgot to extra check the dist files in the npm repo. They were not there and could not be added after the release, so here is the patch.
Cya