Recommend way to patch @theia module typescript files


I’m trying to test a patch to @theia/plugin-ext/src/main/browser/webview/webview-environment.ts, in order to address an issue I’m experiencing (an issue with invalid cspSource given certain values of THEIA_WEBVIEW_EXTERNAL_ENDPOINT, which I’d be happy to make the subject of a separate post or if I’m lucky pull request).

My standard build process is essentially to start with the standard package.json, after which I run yarn.

However, my patched .ts file is always overwritten with the upstream copy. I have prepared a patch file using patch-package, which I have installed to the package.json. It reports patching the .ts file, but the modified code never appears in the .js output:

~/theia # yarn
yarn install v1.22.5
[1/4] Resolving packages...
success Already up-to-date.
$ patch-package
patch-package 6.2.2
Applying patches...
@theia/plugin-ext@1.8.1 ✔
$ yarn run clean && yarn build
yarn run v1.22.5
$ theia clean
Done in 0.48s.
yarn run v1.22.5
$ theia build --mode production
Failed to resolve module: filenamify
(node:6985) DeprecationWarning: Tapable.apply is deprecated. Call apply on the plugin directly instead

Is there a recommended way to apply a patch to the .ts files used for building Theia in this way? I would prefer not to have to build from the git repo.


The TypeScript files are only distributed for debugging. Once those are pulled under node_modules they don’t magically get transpiled to JavaScript again. From there you have two options:

  1. Create a Theia extension that overrides the class implementing the method you wish to change.
  2. Patch the JavaScript files under /lib.

What’s the issue and does it affect Theia 1.8.0?

Hi @paul-marechal.

The issue I’m experiencing arises when using THEIA_WEBVIEW_EXTERNAL_ENDPOINT='{{uuid}}-webview-{{hostname}}'. We use dashes not dots, as we run Theia over HTTPS and rely upon a wildcard SSL certificate for *.{{hostname}}.

The issue I’m experiencing is that cspSource() in webview-environment.ts returns *-webview-{{hostname}} which is later turned into *

This results in browser errors using e.g. the git-graph extension, which uses this.panel.webview.cspSource.

Checking indicates this is an invalid CSP value and indeed this value causes VS code extensions like git-graph to fail.

I’m not sure why it is useful to substitute {{uuid}} with * to generate the CSP, as I have tested (by modifying the js) that disabling this substitution altogether fixes git-graph. N.B. Doing this results in a cspSource() value like, which (at least in git-graph’s case) seems fine.

Ultimately though, I think it’s only safe to replace {{uuid}} with * if {{uuid}} is followed by ., and so my patch (untested) would be something like this:

-         return (await this.externalEndpointUrl()).withPath('').withQuery('').withFragment('').toString(true).replace('{{uuid}}', '*');
+         return (await this.externalEndpointUrl()).withPath('').withQuery('').withFragment('').toString(true).replace(/{{uuid}}\./, '*.');

I’m not sure that this is new in 1.8.0 (I haven’t tested earlier versions), although I did experience a regression in upgrading from 1.3.0 to 1.8.0 without change our previous setting, THEIA_WEBVIEW_EXTERNAL_ENDPOINT='{{hostname}}', which led to console errors refused a websocket connection which I traced to messaging-contribution.ts and one of the allowWsUpgrade checks failing.

1 Like

I opened an issue about this recently

But the snippet you proposed does not replace {{uuid}} by it’s actual value? So it would still break then?

Worth an issue in the main repo :slight_smile:

That’s great you have already found the first issue.

From testing, I think something else in the code is already replacing {{uuid}}, {{hostname}}, etc, with their values. So with my patch, I would still expect to get a working URL.

But I will test this to be sure and raise an issue on the github repo.

I’ve now tested my patch, and have posted this issue on github here: