Initial surface for module API (enough for an ILAG module)

[turt2live]

This layer is intended to represent the actual module API surface for element-web (technically react-sdk). We extract this to a dedicated package for a few reasons:

1. It makes determining module compatibility trivial: compare the module-api dependency of the element-web layer and the module with semver to see if it'll work.
2. This package is mostly just types and very little code, making for a small dependency. A module would not need to pull in the entirety of the react-sdk or similar just to make itself compatible.
3. With a dedicated package, modules are less likely to reach into implementation-specific code to "go around" the module API surface. For example: modules will have a harder time getting access to a MatrixClientPeg (not impossible, but harder).

With this PR, the project gets shifted over to the element-web team for ongoing maintenance. It is treated as a direct dependency of the react-sdk itself and thus maintained by the same team.

Note: There are other layers which are listed as drafts. These drafts are not up for review because they depend on layers like this one to exist and be published. They will be put up for review incrementally.

Upon merge of this PR, I'll publish the package to npm.

---

Part of a series / reference material:

• React layer: Support a module API surface for custom functionality matrix-react-sdk#8246
• Web layer: Wire up module loading to application startup element-hq/element-web#21703
• Demo module: Early module implementation element-hq/element-web-ilag-module#1
• Internal proposal (cannot be public)

[t3chguy]

With this PR, the project gets shifted over to the element-web team for ongoing maintenance. It is treated as a direct dependency of the react-sdk itself and thus maintained by the same team.

There are other prerequisites for this

Such as copying the T- labels, wiring up a bunch of the same CI (Enforce Labels, Sonar, Static Analyses, etc)

[t3chguy]

Couldn't this just grow a peer-dep to js-sdk given it knows it'll have a js-sdk from react-sdk?

[turt2live]

Potentially. I've been trying to avoid the peer dependency style as it'll end up being a slew of warnings for developers (because we won't update the dependency very often)

[t3chguy]

that's fine though because its a peer-dep, you could even specify the min version and say any version from there. >=12.4.1 (replacing with the actual version we introduced TypedEventEmitter)

[turt2live]

until we release a breaking change of the js-sdk and then it is considered unmatched (both logically and by the semver checks - we can't assume it'll continue to compile).

For now I'm not that concerned with typed event emitter support. Documentation can supplement it.

[t3chguy]

Then why not add yet another layer called matrix-js-common or something :P?

[turt2live]

not sure if serious, but it's quite literally on the table for consideration.

[t3chguy]

It'd be a good home for some things for element-desktop to re-use too, like fetchdep.sh

[turt2live]

probably for a larger conversation outside of this PR though ;)

[t3chguy]

This pattern will be very easy to forget about when refactoring, it is very strange

could we not move the module-api up to element-web and then module-api can depend on react-sdk and use components like Spinner etc inherently?

[turt2live]

We're actively avoiding a react SDK dependency because the modules themselves cannot and should not have easy access to that dependency.

[t3chguy]

Bit more reasoning here would be great

[turt2live]

The layer provides two main benefits:

1. It gives us something to check version against implicitly, ensuring we're only including supported modules in our build.
2. It avoids modules depending on the react-sdk either directly or indirectly, reducing risk of developers breaking free of the module system and making bad decisions. The react-sdk is also not a tiny project, so it ultimately saves disk space on developer machines, and it reduces the chances of dependency conflicts when webpack tries to figure out what is going on.
   • A react-sdk dependency would also overly tie a module to an application version when in fact it could likely be supported across breaking changes of the react-sdk: this layer abstraction allows for a module to write code against a standard set of functions and be fine for several releases. Essentially, it allows us to break the app and module API surface separately, a benefit that projects like Synapse don't have.

Together, these are reason enough to warrant the new layer. While the layer itself is a bit annoying (requires someone to keep an eye on it), it's expected to be even less traffic than the widget-api or analytics-events dependencies.

[turt2live]

With this PR, the project gets shifted over to the element-web team for ongoing maintenance. It is treated as a direct dependency of the react-sdk itself and thus maintained by the same team.

There are other prerequisites for this

Such as copying the T- labels, wiring up a bunch of the same CI (Enforce Labels, Sonar, Static Analyses, etc)

this is all counted as "ongoing maintenance" btw :P (we don't have any of this infrastructure on the widget-api, for instance)

also, considering it's a bit in flux at the moment I'd rather switch once we have everything set up fully on the other layers. There's also no real reason to overload this PR at the moment (I think).