search

matrix-org / matrix-js-sdk

Matrix Client-Server SDK for JavaScript
Apache License 2.0
1.53k stars 580 forks source link

Export a proper public interface instead of a monolithic chunk #4339

Open turt2live opened 1 month ago

turt2live commented 1 month ago

For cases where a consumer only needs a few functions instead of the entirety of matrix, like in https://github.com/matrix-org/matrix-react-sdk/pull/12871 - they shouldn't have to consume 1mb of JS to do simple things.

This may change the project more towards a library than an SDK though, and warrants team discussion.

robintown commented 1 month ago

Related: https://jaydenseric.com/blog/optimal-javascript-module-design

richvdh commented 1 month ago

Related: https://jaydenseric.com/blog/optimal-javascript-module-design

Interesting, thanks for the link.

I think that smaller JS modules - that only export one thing - can be a good idea for some packages (the article cites lodash, and it's right). But lots (most?) of the js-sdk just isn't designed to work that way -- it's not like you can meaningfully import Room without importing MatrixClient, and MatrixClient depends on Room, so there's nothing to be gained by doing so. Worse, if every file becomes part of the public interface of the js-sdk, it becomes hard to maintain without breaking backwards compat every release, and hard to use because you can't find the right interface.

So sure, +1 to smaller public interfaces that don't import the entire world, but we need to continue to be clear which modules are public and which are internal, rather than going back to open season on them.