Track extension es6 output migration

[jrieken]

We have changed our compile to emit ES6 JavaScript, instead of ES5. That means let or const don't become var etc, it also means that classes are emitted as classes, not as functions.

There are extensions that emit ES5 JavaScript and that extend from our API types. The code usually looks like this:

var PathCompletionItem = (function (_super) {
    __extends(PathCompletionItem, _super);
    function PathCompletionItem(filename, isfile) {
        _super.call(this, filename);
        this.foo = 1;
    }
    PathCompletionItem.prototype.bar = function () {
        this.foo += 1;
    };
    return PathCompletionItem;
}(vscode.CompletionItem));

The challenge is that calling a class-constructor from a function extending it, isn't possible and requires a workaround. We have the es5ClassCompat-util for that. However, there are only eight extensions that use this pattern and this issue track the migration to emitting ES6 code.

• https://github.com/vscode-contrib/vscode-versionlens/issues/132
• Migration: please emit ES6 output pmneo/ts-importer#51
• Migration: please emit ES6 output iann0036/cloud9-sync#16
• Migration: please emit ES6 output xiaogangya/markdown-authoring#6
• Migration: please emit ES6 output LambdaFactory/Neptune-public#25
• Migration: please emit ES6 output bbenoist/vscode-quicktips#1
• https://marketplace.visualstudio.com/items?itemName=QuantumSheep.now-vscode (GH link broken)
• Migration: please emit ES6 output JeisonJHA/vscode-shortcut#1
• Migration: please emit ES6 output vshaxe/vshaxe#317

Calling static functions using the new keyword (see #69533)

• Don't use new vscode.Uri.file inu1255/vscode-easy-greenjs#1
• Don't use new vscode.Uri.file Gruntfuggly/todo-tree#133
• vscode.uri.file is not a constructor - The Journal window fails to load anything Gruntfuggly/vscode-journal-view#11
• Don't use new vscode.TextEdit.replace mikeburgh/vscode-xml-format#5

[jrieken]

Types that are being extended by functions (this includes only extension code, not code that is in node_modules programmed against vscode-API)

CompletionItem
Disposable
TreeItem
CodeLens

[iann0036]

Done. Good luck!

[Gama11]

However, there are only eight extensions that use this pattern and this issue track the migration to emitting ES6 code.

I think your detection method might be flawed and there might actually be more extensions affected. The Haxe extension (naturally) uses Haxe-generated JS, which uses this pattern:

vshaxe.view.dependencies.Node = function(parent,label,path,type) {
	vscode.TreeItem.call(this,label);
	...
}
vshaxe.view.dependencies.Node.prototype = $extend(vscode.TreeItem.prototype,{
	...
}

Where Haxe defines $extend as:

function $extend(from, fields) {
	var proto = Object.create(from);
	for (var name in fields) proto[name] = fields[name];
	if( fields.toString !== Object.prototype.toString ) proto.toString = fields.toString;
	return proto;
}

The challenge is that calling a class-constructor from a function extending it, isn't possible and requires a workaround. We have the es5ClassCompat-util for that.

I'm a bit confused by this - does that mean that with that workaround in place, extensions using ES5 style JS should continue to work fine (but you're looking to remove the compatibility layer soon)? That already seems to not be the case, there's an error when expanding a node in the Haxe Dependencies View with current Insider's Builds (a509265).

[jrieken]

Good catch @Gama11. I obviously don't know all patterns how functions extend classes/function. I have created a tracking item for the haxe extension.

does that mean that with that workaround in place, extensions using ES5 style JS should continue to work fine (but you're looking to remove the compatibility layer soon)?

Yes, everything should still work (your code won't load if not) but we are keen on removing the workaround because so few extensions rely on it.