Cannot develop my extension against latest

[jrieken]

With the latest changes from #970 I can have vscode: * as engine and retrieve the latest vscode.d.ts to prepare my extension for the future. Tho when having it configured like that VS Code will not load my extension because the engine specifier isn't specific enough. We should agree and what we want here.

[jrieken]

@alexandrudima fyi

[bpasero]

I would expect the validation to not kick in when "*" is specified.

[alexdima]

@jrieken An extension that uses the vscode api (aka has a main field in package.json) is not allowed to use engines.vscode: "*". (Notable exception: extensions in our source tree which always compile against master and don't make it in the store). I hope you understand why: allowing that means extensions would make it in the store with * and we would never be able to introduce api breakage nor filter at browse/install time only compatible extensions.

I don't know how you could signal to the download tool to get you the vscode.d.ts on master, but IMHO it should not be engines.vscode: "*". @bpasero Perhaps the vscode.d.ts download tool can be made available also as a command line where the version is passed in?

[bpasero]

It already is a command: https://github.com/Microsoft/vscode-extension-vscode/blob/master/bin/install and it could accept a version argument to override. It would be nicer though if you could override a value from package.json through the command line and just specify "*" as engine for VSCode.

[bpasero]

@alexandrudima another idea would be to allow "*" as engine but only in combination with "private: true" to disable validation. This then should be something our publish tool reads and understands to prevent from publishing it to the store.

[alexdima]

I personally would prefer to keep things simple:

vscode.engine is required and must be some specific value if your extension uses vscode api

Perhaps we should do the following:

• as soon as we release VSCode version X, make a tag for it in github
• immediately afterwards deliver to master a version bump to Y such that we never build by accident or intentionally version X again

The two above points are good practice IMHO.

Then:

• an extension builder that wants to work against VSCode/master modifies the engines.vscode to ^Y
• the vscode.d.ts download tool can fetch https://raw.githubusercontent.com/Microsoft/vscode/master/package.json and download master if the version in there matches Y

[bpasero]

Yes, +1 for updating our version in package.json as soon as we release. We currently have 0.10.6 in there although we are already working on 0.10.7, though that is not yet released. To be correct, it would need to be something like 0.10.7-pre (= pre release). Is our extension validator fit for pre releases?

I think it is a fair fallback for the vscode.d.ts script to check if the version specified matches with master and then also picking master if that is the case.

[alexdima]

+1 our master package.json should already be 0.10.7 or 0.10.7-pre.

0.10.7-pre should work just fine, there's even unit tests for that: https://github.com/Microsoft/vscode/blob/8f35cc4768393b25468416829e980d7550619fb1/src/vs/platform/plugins/test/node/pluginVersionValidator.test.ts#L104

[bpasero]

I have pushed a fix for the vscode.d.ts module to support picking up our version on master and I pushed 0.10.7 as version to master. I am not sure we need the "pre"-tag because we are not publishing VSCode to NPM and in fact we are using 0.10.7 as if it was already released (just nightlies). I am fine with either pre or not pre and both should work now.

@jrieken if you set your engine to 0.10.7 things should work and the vscode.d.ts picked up from master.

[jrieken]

works!