targeting es6 as a base (without transpiling to es5)

[akosyakov]

Motivated by #5901:

LSP dependencies are targeting es6 now, we are forced to use babel in order to transpile es6 to es5 classes for these dependencies

There is no issue with supporting es6 in browsers right now, but:

• there is an issue with Object.keys for Theia and inversifyjs. TS compiles it to be compatible with es3 when a target is es5, not es6. So switching breaks its semantic. We can fix it though and propose PR for invesifyjs.
• phosphorjs transpiled to es5, with es6 code where is no way to extend them with es6 code. We can propose a PR to distribute phosphorjs for different targets or transpile to es6 in our fork.

Moving to es6 will reduce amount of generated code and reduce bundle sizes as consequences. Also some features as classes will be implemented natively by browsers.

[akosyakov]

To my surprise it caused issues only in browser code, in Node.js es5 classes seem to extend es6 classes without issues. I would leave it out from Monaco migration, could be done separately.

[paul-marechal]

• there is an issue with Object.keys for Theia and inversifyjs. TS compiles it to be compatible with es3 when a target is es5, not es6. So switching breaks its semantic. We can fix it though and propose PR for invesifyjs.

What does that mean? Would it really be an issue when using Object.keys() ?

To my surprise it caused issues only in browser code, in Node.js es5 classes seem to extend es6 classes without issues.

You mean that from es6 we can extend es5 classes? In the browser, TypeScript seems to complain, yet runtime looks fine: playground

[akosyakov]

Many VS Code extensions are compiled against es5 if we recompile plugin host types to es6, they won't work. We should make sure that these classes remain es5 compatible.

[paul-marechal]

Apparently VS Code slightly transforms some classes to be compatible with es5 code while writing es6: https://github.com/microsoft/vscode/blob/15beb36ccf0d70bf26c8e308e17093902b71e927/src/vs/workbench/api/common/extHostTypes.ts#L18-L27

[paul-marechal]

I experimented with it on the TS Playground, this @es5ClassCompat decorator works well when trying to extend ES6-style classes from ES5-style classes. The plugin host will support ES6 anyway, so we "just" need to guard against different semantics?

[kittaakos]

Related: #6761

[sgraband]

@akosyakov

I am currently looking into this and have a few questions, regarding your comments. Mainly i was wondering what regressions you might expect/experience with phosphor and inversify, as i could not find any problems, when trying this out. Could you maybe elaborate a bit on this? Or do you have an example, where the usage of inversify/phosphorjs would lead to problems? Thanks in advance.