:sparkles: NPM workspaces and Migrate to Vite for HMR in Webview Package

[ibolton336]

PR changes:

• Replace Webpack with Vite for webview-ui. In development mode, the extension is able to consume the webview running on a local vite dev server which allows for HMR and a rapid development experience.
• Adds npm workspaces implementation for dependency sharing (typescript) & better handling of build / dev scripts for development / production. Lifts all eslint & prettier configuration to project root.
  • Creates a new shared package that holds shared code between webview-ui and extension.
  • Can now run npm install && npm run dev from the project root to start both development servers (webpack for extension & vite for ui)
  • Vite enables HMR for webview development. Also removes need for complex plugin configuration - only plugin needed now is the vite react plugin
• Adds a new debugger pre launch task to start dev servers. This allows us to start all development servers & open the debugger with f5.

Fixes #77

TODO:

• Replace webpack copy plugin with something more robust
• Address vscode extension state management
• Improve webview messaging

[ibolton336]

Does adopting vite require setting up webview-ui as a separate project under vscode? That is a bit concerning for knowing how to work in the project.

What does the future look like? The webview as it's own project and then any regular extension points go in the base vscode tree?

Would setting up a more typical multi-workspace project make more sense? Something like how tackle2-ui is setup? The root project has build related configs, then common is stuff shared between webview and "normal" extensions, then webview, then "normal" extensions?

The idea is here is based off the continue approach where they have a separate GUI project that remains separate from the extension code. Still working out what that looks like for us - will need to rethink CI with your input when the time is right.

[sjd78]

The idea is here is based off the continue approach where they have a separate GUI project that remains separate from the extension code. Still working out what that looks like for us - will need to rethink CI with your input when the time is right.

I understand what you're trying to do now. That is a great bit of info to put in the PR description

Should the webview/gui project then live outside of the vscode project tree? That way it is obvious that the webview is intended to be independent of the vscode work.

[ibolton336]

• Hitting the run button in vscode to launch another vscode with the extension running (and the webview embedded in it)

This one was a head scratcher - couldn't get vscode debugger to open the launch.json unless I opened the nested vscode dir. Wanted to be able to launch the debugger from the project root, so had to create a new .vscode/launch.json in the project root.

Doing npm run and having vscode with the extension running This should now word from the root of project with npm run dev. Updated the project root readme to reflect these dev experience changes.

Doing a build to static files to be packaged I'll need to tinker with what is here to see which one of those things work etc. Working with running a command and then also hitting the run button is clunky but probably works ok for now. Feels like it could be streamlined.

This does work via webpack copying the built assets from vite build output into the out/webview directory. The copy plugin is configured to only run in prod mode.

Agree that the npm run dev command could be kicked off by the launch.json in some fashion. I will look into getting that working.

[ibolton336]

Beyond that, it would be good to see the messages that get sent between the webview and the extension be well defined somewhere like "webview-api" or something. No better name comes to mind at the moment. Then the webview would grab an instance of that object/whatever and the actions would be all well defined. It is quite interesting to conceptualize the webview as an iframe in a browser that only has message posting access. I'm not sure that's actually the case here.

Interesting point(s) and I think that there should be issues created if they don't exist already to capture the messaging changes & the state handling changes.