-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Bump @matrix-org/react-sdk-module-api from 1.0.0 to 2.0.0 #25986
Bump @matrix-org/react-sdk-module-api from 1.0.0 to 2.0.0 #25986
Conversation
Signed-off-by: Dominik Henneke <[email protected]>
// in the Client-side surface lead to a major bump even though the Module-side surface stays | ||
// compatible. We aim to not break the Module-side surface so we maintain a list of compatible | ||
// older versions. | ||
const backwardsCompatibleMajorVersions = ["1.0.0"]; |
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.
This seems fine to me for now but I wonder if this wouldn't easily get unwieldy in future? Imagine we end up having a couple more backwards compatible versions in this list. Wouldn't the act of deciding whether or not a new version is backwards-compatible with all of the versions listed here become ever more cumbersome?
If this is a problem with differentiating between the client-facing and the module-facing API version, could we somehow define separate version numbers for these two?
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 think one issue here is that @matrix-org/react-sdk-module-api
(and also matrix-widget-api
) are both no APIs that should be updated in an automated fashion because they require manual changes in the matrix-react-sdk
most of the time.
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.
@Johennes: we discussed this in #element-dev yesterday. I suggested this approach as a pragmatic solution to the compatibility problem for now. Changing the way we manage API versions altogether would involve a bunch more thinking and work, and we can do it in future if and when this approach becomes unmanageable.
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.
Yes, I've followed that discussion and agreed that this seems fine for the moment. Point taken on us returning to this once it does actually become unwieldy.
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.
Looks sane
Depends on matrix-org/matrix-react-sdk#11395.
This PR includes two more changes:
1. Have Element compatible with multiple versions of the Module API at the same time
Based on the discussion in #element-dev:matrix.org. Gist: The semantic version of the Module API is not a good indicator for the compatibility of a module to the client. Element can accept modules that run on older versions of the module api as long as the Module-Surface-API stays compatible. If any non-backwards compatible change to the Module part of the API happens, this list must be reset.
2. Make sure only a single copy of the Module API is used
This was already the case without 1., but now it is inevitable. Some parts of the Module API rely on global variables, so every module must use the same instance of the module API package. 1. requires that all modules can work with all compatible versions of the Module API, so it should be acceptable to let webpack force to resolve it to a single instance.
An example where this breaks. Note that left shows the fallback textfield and right the correct component.
develop
branchThis error will only be testable when we have e2e tests for the Module API. I hope this discussion doesn't block this PR.
Checklist
This change is marked as an internal change (Task), so will not be included in the changelog.