Update VS Code to 1.50.0 #2204
Update VS Code to 1.50.0 #2204
Conversation
- The .js build files are no longer committed so they're gone. - ParsedArgs and EnvironmentService are now NativeParsedArgs and NativeEnvironmentService. - Interface for environment service was moved. - getPathFromAmdModule was deprecated.
It's a new module used by 1.50.0.
It needs to have the scheme otherwise when resolving these modules the loader will default to the file scheme and fail to fetch.
This matches with the html in the VS Code repo and also fixes a problem with the worker which loads HTML using data: and then can't load any scripts because 'self' doesn't work.
This makes the fetch work independently of the worker's origin which is no longer the same as the main thread (the main problem is the inability to send cookies without setting SameSite to None).
code-asher
force-pushed
the
vscode-1.50.0
branch
3 times, most recently
from
70292c4 to
c27f2d8
Compare
Removing them just for peace of mind even though they seem to get filtered out later. This line is meant to only add remote extensions that aren't capable of running in the browser. If they are browser-capable they don't need to run in our shimmed Node environment.
code-asher
force-pushed
the
vscode-1.50.0
branch
from
c27f2d8 to
daf204e
Compare
| input = updateExtensionPackageJSON(input, (data) => { | ||
| delete data.scripts; | ||
| - delete data.dependencies; | ||
| + // https://github.com/cdr/code-server/pull/2041#issuecomment-685910322 |
There was a problem hiding this comment.
I believe this was an accidental removal.
There was a problem hiding this comment.
Yup, for all of these .js build files, they're no longer committed.
Check out the comment on e3699cf for a bit more info.
There was a problem hiding this comment.
We have to move the patches into the .ts files then right?
There was a problem hiding this comment.
Yup, they're already there. They don't show up in the diff though since we already had 'em.
| } | ||
| exports.streamToPromise = streamToPromise; | ||
| function getElectronVersion() { | ||
| + return process.versions.node; |
| -const yarnrcPath = path.join(root, 'remote', '.yarnrc'); | ||
| -const yarnrc = fs.readFileSync(yarnrcPath, 'utf8'); | ||
| -const version = /^target\s+"([^"]+)"$/m.exec(yarnrc)[1]; | ||
| +const version = process.versions.node; |
| --- a/src/vs/platform/product/common/product.ts | ||
| +++ b/src/vs/platform/product/common/product.ts | ||
| @@ -30,6 +30,12 @@ if (isWeb) { | ||
| @@ -37,6 +37,12 @@ if (isWeb || typeof require === 'undefined' || typeof require.__$__nodeRequire ! |
There was a problem hiding this comment.
Why was this change required?
There was a problem hiding this comment.
This is just the context of the patch, so VS Code made this change. This patch is seriously too hard to diff.
| @@ -1049,6 +1024,21 @@ index 0000000000000000000000000000000000000000..0d2e93edae2baf34d27b7b52be0bf496 | |||
| + } | |||
| + } | |||
| + | |||
| + async $fetchExtension(extensionUri: UriComponents): Promise<VSBuffer> { | |||
There was a problem hiding this comment.
Why do we have to implement this?
There was a problem hiding this comment.
I made a comment on f20f7ac but the gist is that the worker is now in a separate origin so it can't fetch the extension (cross origin domain issues) and even if you resolve that by setting the appropriate headers it still doesn't work because it doesn't send the cookie. So instead I have it asking the main thread to fetch the extension. Since this mechanism already exists for the extension to communicate with the main thread (for example to make file read calls) I figured it was a decent solution.
There was a problem hiding this comment.
I should comment this in the code and not just in the commit.
Planning on making a 3.6.1 release with this.