editor/code: Allow to apply static analysis for codes opened in webview

[tetsuharuohzeki]

This pull request introduces build phase to bundle a code opened in a webview by esbuild.

By this change, we are able to apply a static analysis for codes that are opened in webview.

As a caveat, we might confuse the execution context between vscode extension and webview after this change. For example, you may be able to touch DOM that is not actually in the vscode extension context but TypeScript does not warn it. I think this would not be a problem in a almost case by pushing codes into src/webview/ directly.

To prevents this problem, we need introduce a separated npm workspace to use an another tsconfig.json. But I think we don't have to do it in this moment. We should postpone it to the future.

[tetsuharuohzeki]

I rebased on the latest master branch

[bors]

☔ The latest upstream changes (presumably #15265) made this pull request unmergeable. Please resolve the merge conflicts.

[lnicola]

We're back on 1.75 since #15333.

[tetsuharuohzeki]

• v1.78 updates to Electron 22.
• Before v1.78, vscode uses Electron 19 (Chromium 102.0.5005.167 and Node.js 16.17.1).

I'll update to:

- // VSCode v1.78 (Electron 22) uses Chromium 108.
+ // VSCode v1.75 (Electron 19) uses Chromium 102.

[lnicola]

For example, you may be able to touch DOM that is not actually in the vscode extension context but TypeScript does not warn it.

That's pretty bad, but I don't know if it will become a problem in practice. On the other hand, being able to move out all that code is nice.

[Veykril]

That's pretty bad, but I don't know if it will become a problem in practice. On the other hand, being able to move out all that code is nice.

I think this is fine for now, we don't use a lot of webviews, nor do we much with them.

[lnicola]

I think this is fine for now, we don't use a lot of webviews, nor do we much with them.

I read that a bit differently -- being able to touch (at compile-, not run-time) the browser DOM from the main extension code. But I might be wrong.

[tetsuharuohzeki]

I think this is fine for now, we don't use a lot of webviews, nor do we much with them.

I read that a bit differently -- being able to touch (at compile-, not run-time) the browser DOM from the main extension code. But I might be wrong.

@lnicola @Veykril

Yes. By the current design, we can touch DOM objects that does not exist in the vscode extension scope at the compile-time (at type level). For example, the current design does not prevent that VSCode's intellisense suggests window.navigator on inputting w when we edits editors/code/src/config.ts

To prevent fragile, I think we may take an approach to use npm workspace and typescript's project reference to tell a workspace dependency to typescript compiler.

npm script cannot run it's with workspace dependency topological order npm/rfcs#548. Thus I choose typescript's project reference because I don't think it's a bit complex to introduce a monorepo tools nx or turborepo to this repository that already contains 2 programming language in heterogeneously.

But this requires the change directory hierarchy and it would be major surgery.
I'm hesitate to do it in this pull request.

[lnicola]

npm script cannot run it's with workspace dependency topological order npm/rfcs#548.

Can we run tsc and whatever twice instead of relying on npm script or an external tool?

[tetsuharuohzeki]

Can we run tsc and whatever twice instead of relying on npm script or an external tool?

TypeScript's project reference automatically runs tsc for all participated workspace by invoking tsc once.

[Veykril]

I'm indifferent to this, I have no typescript tooling knowledge so I can't really judgbe, but I'm fine with merging this since it looks beneficial.

[bors]

☔ The latest upstream changes (presumably #15728) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

Having given this another look,

Yes. By the current design, we can touch DOM objects that does not exist in the vscode extension scope at the compile-time (at type level). For example, the current design does not prevent that VSCode's intellisense suggests window.navigator on inputting w when we edits editors/code/src/config.ts

does seem rather bad. So I'm more inclined to not merge this now after all

[tetsuharuohzeki]

Okay, I withdraw this pr once. Thank you for discussions