-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ NPM workspaces and Migrate to Vite for HMR in Webview Package #71
Conversation
589bcc6
to
a586d8e
Compare
2a16b13
to
5bec3b1
Compare
d45b207
to
8011a56
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
8011a56
to
51c2f3a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see anything technically wrong with this. With it we need to document how this changes the development workflow. Either the vscode README.md or contributing doc or some combination of the two.
1b064f1
to
b96dc7e
Compare
fef8f5b
to
6613a49
Compare
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. |
c6fe38b
to
6b6f2bb
Compare
1ca56c8
to
3c82043
Compare
88b03dc
to
02388e5
Compare
Signed-off-by: Ian Bolton <ibolton@redhat.com>
Signed-off-by: Ian Bolton <ibolton@redhat.com>
…ebpack Signed-off-by: Ian Bolton <ibolton@redhat.com>
Signed-off-by: Ian Bolton <ibolton@redhat.com> Signed-off-by: Ian Bolton <ibolton@redhat.com>
Signed-off-by: Ian Bolton <ibolton@redhat.com>
Signed-off-by: Ian Bolton <ibolton@redhat.com>
1adbcaf
to
02cae1e
Compare
ffb1ffa
to
3c8417c
Compare
Signed-off-by: Ian Bolton <ibolton@redhat.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks very close to being able to open the repo root directory in vscode and then work on both the vscode/
extension and the webview/
component all at the same time.
Running things is kinda interesting given the target. So really I see a bunch of things going on:
- Hitting the run button in vscode to launch another vscode with the extension running (and the webview embedded in it)
- Doing
npm run
and having vscode with the extension running - 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.
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.
I will look again in the morning with coffee.
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.
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. |
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. |
bc93dde
to
8625758
Compare
Signed-off-by: Ian Bolton <ibolton@redhat.com>
c1f6f74
to
82d720a
Compare
Signed-off-by: Ian Bolton <ibolton@redhat.com>
96d9211
to
f035eb1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
68f14c0
to
b19fb37
Compare
Signed-off-by: Ian Bolton <ibolton@redhat.com>
3095232
to
5f3f1a6
Compare
PR changes:
shared
package that holds shared code between webview-ui and extension.Fixes #77
TODO: