Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tsconfig: transpile to es6 #6060

Closed
wants to merge 1 commit into from
Closed

tsconfig: transpile to es6 #6060

wants to merge 1 commit into from

Conversation

paul-marechal
Copy link
Member

What it does

Transpile from es5 to es6 to accomodate libraries written in es6.

Reason is that es6 is backward compatible with es5 but it is not forward
compatible.

Closes #5902.

How to test

To be defined? yarn test should terminate successfully.

Review checklist

Reminder for reviewers

Transpile from es5 to es6 to accomodate libraries written in es6.

Reason is that es6 is backward compatible with es5 but it is not forward
compatible.

Signed-off-by: Paul Maréchal <paul.marechal@ericsson.com>
@paul-marechal paul-marechal added the dependencies pull requests that update a dependency file label Aug 28, 2019
@paul-marechal paul-marechal requested a review from a team as a code owner August 28, 2019 22:32
@akosyakov
Copy link
Member

To be defined? yarn test should terminate successfully.

It is not enough, we should use electron and browser apps and check that such constructions like instanceof are supported. As far as I know it probably won't work for phosphor js yet: phosphorjs/phosphor#413 i.e for any es5 code from dependencies which we extend.

@paul-marechal
Copy link
Member Author

paul-marechal commented Aug 29, 2019

i.e for any es5 code from dependencies which we extend.

Why?

I just launched the browser and electron application, I was unable to find regressions UI-wise.

Just tried on the TypeScript playground again, and ES5 classes seem to be extendable from ES6 code: playground setup

@paul-marechal
Copy link
Member Author

To be more clear, my claims are:

  • I wasn't able to find anything broken in this PR (but I am asking for help finding issues).
  • ES6 classes can extend ES5 classes, and class-specific operations still work (i.e. instanceof).
  • Only issue I had was related to the JsonRpcProxyFactory, since it relied on a for..in to list all methods (in old ES5), this seems to be changed in ES6: we have to be more clever in the lookup in order to fetch everything. I noticed the regression from the tests. I already took care of it in this PR.

@paul-marechal paul-marechal requested review from a team and removed request for a team August 29, 2019 22:58
@paul-marechal
Copy link
Member Author

Oops, the core team is a bit overkill to ask on a PR, or is it intended that it would ping 21 people?

@akosyakov
Copy link
Member

akosyakov commented Aug 30, 2019

Oops, the core team is a bit overkill to ask on a PR, or is it intended that it would ping 21 people?

Why not? All these people are Theia committers, i.e. responsible for helping to maintaining Theia. If someone just wants to contribute they don't need write access, other committers can review and help to land their work.

@akosyakov akosyakov requested a review from a team August 30, 2019 04:33
@@ -80,7 +80,7 @@ export class JavaClientContribution extends BaseLanguageClientContribution {
protected onReady(languageClient: ILanguageClient): void {
languageClient.onNotification(ActionableNotification.type, this.showActionableMessage.bind(this));
languageClient.onNotification(StatusNotification.type, this.showStatusMessage.bind(this));
languageClient.onRequest(ExecuteClientCommand.type, params => this.commandService.executeCommand(params.command, ...params.arguments));
languageClient.onRequest(ExecuteClientCommand.type, params => this.commandService.executeCommand(params.command, ...params.arguments || []));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to change it? Does it mean a breaking change for all JSON-RPC using varargs? Could we avoid it?

Copy link
Member Author

@paul-marechal paul-marechal Aug 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switching compilation target to ES6 made TypeScript detect that params.arguments can be undefined meaning that it could not be unwrapped. It wouldn't let me build.

It is breaking if we try to unwrap undefined values in other places.

@akosyakov
Copy link
Member

Let's have a look at it when Monaco upgrade is finished.

@akosyakov
Copy link
Member

@AlexTugarev Do you remember how to reproduce inversify/InversifyJS#928 in Theia?

@AlexTugarev
Copy link
Contributor

@akosyakov there was at least one case of an injection with bogus constructor arguments as described in the issue. the included code snipped should tell us if it was fixed in the meanwhile. the execution should produce the same output for es5 and es6.

I guess 74e5ac7#diff-7bcf3cc870db868677d26d618e924394 is related.

@akosyakov
Copy link
Member

akosyakov commented Aug 30, 2019

@AlexTugarev It means that it was only worked around in this repo, but does not guarantee it won't break for any downstream projects which can use such bindings.

Another issue that it is going to cause rippling effect by forcing all extensions and products be recompiled to es6. cc @svenefftinge

If we do it we have to collect all possible pitfalls and prepare PRs for extensions under theia ide org. Maybe we discuss it first, seems to be like a lot of work for us and extenders. It is not a showstopper for Monaco migration right now and can be postponed.

@paul-marechal
Copy link
Member Author

paul-marechal commented Aug 30, 2019

@AlexTugarev After trying out your code snippet on inversify/InversifyJS#928, it looks like inversify sets to undefined arguments following ones marked as @optional() when targeting es6:

    constructor(
        @inject(DepC) c: DepC,
        @inject(DepB) @optional() b: DepB = {b: 0},
        @inject(DepA) a: DepA,
        @inject(DepB) @optional() d: DepD = {d: 0},
        @inject(DepA) e: DepE,
        @inject(DepB) @optional() f: DepF = {f: 0},
    )

In this example, a and e will be undefined. This is definitely a bug, but if we put all optional parameters at the end, no more undefined values. Not saying this is not an issue, but it lessens the problem a bit (I find it odd to interleave optional parameters like this).

@paul-marechal
Copy link
Member Author

paul-marechal commented Aug 30, 2019

It is not a showstopper for Monaco migration right now and can be postponed.

Ok

Another issue that it is going to cause rippling effect by forcing all extensions and products be recompiled to es6.

@akosyakov Indeed, since es5 extensions will likely break when importing updated es6 core components... Does that mean that we should systematically use babel to ensure everything is transpiled to the oldest ecma spec?

You also mentioned that babel was a no-go with the plugin extension, how so?

@AlexTugarev
Copy link
Contributor

it looks like inversify sets to undefined arguments following ones marked as @optional() when targeting es6:

@marechal-p that would be a changed behavior then. what I reported back then was that even optionals a not injected properly in subclasses.

@paul-marechal
Copy link
Member Author

paul-marechal commented Aug 30, 2019

what I reported back then was that even optionals a not injected properly in subclasses.

Ah indeed you are right, I only noticed the odd undefined values. After more testing, it is any parameter with a default value that breaks inversify, optional or not.

@akosyakov
Copy link
Member

akosyakov commented Sep 2, 2019

Indeed, since es5 extensions will likely break when importing updated es6 core components... Does that mean that we should systematically use babel to ensure everything is transpiled to the oldest ecma spec?

Not sure we want to run babel on the whole codebase, it could increase the build time significantly. In Monaco PR i only use babel to down compile several es6 dependencies.

You also mentioned that babel was a no-go with the plugin extension, how so?

backend does not go through webpack, unfortunately. But in monaco PR it is turned out to be not an issue to use es6 dependencies for the backend, i.e. we don't extend anything from them.

@akosyakov
Copy link
Member

See another point which we should not overlook: #5902 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

targeting es6 as a base (without transpiling to es5)
3 participants