Do something about ES6 exporting
Recently we're starting to want to pull in libraries that export, or have dependencies that export, ES6. As far as I can tell, there are no guidelines or structure whatsoever in NPM / the JS ecosystem on what language NPM modules are exported as, and now that any vaguely recent node version and all modern browsers support ES6, the answer increasingly seems to be ES6 rather than ES5.
Our options are:
- Continue to export ES5 by babeling everything, dependencies and all (slow)
- Continue to export ES5 by babeling only specific dependencies (major faff to keep the list of babel-ed depds up to date)
- Switch to exporting ES6
I would suggest switching to exporting ES6, which is well supported in recent browser and node versions.
(partial) list of projects that depend on js-sdk, whose build we could potentially break: https://www.npmjs.com/package/matrix-js-sdk?activeTab=dependents Thinking if it would be ok to switch to exporting ES6 if we'd release it as a major version change (0.x)...?
+1 to ES6 and bumping the version
Seems reasonable: the implication of this, of course, is that we stop babel-ing our source files (unless we need to babel down to ES6) since if we are exporting ES6 we might as well export everything in ES6.
Can I hop in to this?
@dbkr has made an attempt a while back in https://github.com/matrix-org/matrix-js-sdk/pull/817. Perhaps building on that and fixing the remaining issues would be a way forward here.
I’d suggest to use rollup with its plugins. Also it’ll allow to bundle browser version inside npm package.
Currently we need to download it from github releases which is really inconvenient.
Another benefit from ES6 version is that during development of client web app, unused functionality will be shakes out
https://github.com/matrix-org/matrix-js-sdk/pull/931 has added a tiny amount of ES 6 (via the dependency base-x) which will be released as 2.0.0 because of the breaking change for syntax.
This issue remains though, because we haven't yet started exporting ES 6 for the SDK's own code. When we do so, it will no longer be a breaking change, so most likely a MINOR version will be appropriate.