Bump @matrix-org/react-sdk-module-api from 1.0.0 to 2.0.0

[dhenneke]

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 branch	this PR

(checkout develop, add "@vector-im/element-web-ilag-module@0.0.4" to the build_config.yaml, open the url to a public room in an incognito tab, and try to join as guest)

This error will only be testable when we have e2e tests for the Module API. I hope this discussion doesn't block this PR.

Checklist

• Tests written for new code (and old code if feasible)
• Linter and other CI checks pass
• Sign-off given on the changes (see CONTRIBUTING.md)

---

This change is marked as an internal change (Task), so will not be included in the changelog.

[Johennes]

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?

CC @t3chguy / @richvdh

[dhenneke]

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.

[richvdh]

@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.

[Johennes]

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.

[t3chguy]

Looks sane