feat(extension): add update/install and cargo-e sync functionality #19
Conversation
davehorner
commented
Jun 13, 2025
davehorner
commented
- Added commands to update, package, install, and broadcast extension updates across machines
- Enabled cargo project detection with Cargo.toml and cargo-e target selection during sync
- Added support for handling incoming cargo-e sync events via WebSocket
- Improved status bar UI and notifications for room ID and WebSocket events
- Updated version to 0.0.57 and enhanced package-lock with glob and related dependencies
- Bumped changelog for version 0.0.6
|
I have about 60+ builds of this thing I've done over the last day. I setup sync for vsce extensions. So you can do a sync on multi-build and it will detect the package.json and the engine(vscode) and perform the package and install, and reload the window. I added a status bar panel that shows the version number of the extension. I added a reload-all-windows and a multiBuild.broadcastUpdateAndInstall which should work but do not. I am not sure about that, but the broadcast was something I tried before I came up with the idea to support vsce in sync. There is something about git pulls that I am finding myself not getting messages past that point, and then if I do it twice, the second time it syncs ok and runs the target. So, this PR is more of a communication and not a ready to submit. there are a lot of little things like sorting the targets and the cargo.toml. |
|
Wow, you've been busy! :D
Oh right, I'll set it to draft in that case. Let me know if that's not your intent. |
|
draft is good. any idea why I can't seem to get messages to the other windows that are not sync? I can see sync go across all the windows. with the extension reload, it reloads the current window. I should be able to broadcast a message to the other vscode windows as they are connected to the websocket. almost leads me to extending sync in ways it should not. I will play some more; lmk if anything rings a bell. |
I hope this is helpful, I opened a new discussion so we can focus on the sync issue: Let's discuss the sync problem there. Edit: I posted my logs here so you can see what good looks like: |
| @@ -23,6 +23,7 @@ your `settings.json` file across all of your computers. | |||
| ## How to use | |||
|
|
|||
| **Prerequisites:** | |||
| - To package you will need `npm install -g @vscode/vsce` | |||
There was a problem hiding this comment.
| - To package you will need `npm install -g @vscode/vsce` |
Fixed in:
- Added commands to update, package, install, and broadcast extension updates across machines - Enabled cargo project detection with Cargo.toml and cargo-e target selection during sync - Added support for handling incoming cargo-e sync events via WebSocket - Improved status bar UI and notifications for room ID and WebSocket events - Updated version to 0.0.57 and enhanced package-lock with glob and related dependencies - Bumped changelog for version 0.0.6
nbolton
force-pushed
the
feature/a_lot_of_things_to_review
branch
from
ccbec3b to
24349bd
Compare
| { | ||
| "command": "multiBuild.updateAndInstall", | ||
| "title": "Multi-Build: Update, Package, and Install Extension" | ||
| }, | ||
| { | ||
| "command": "multiBuild.broadcastUpdateAndInstall", | ||
| "title": "Multi-Build: Broadcast Update/Install to All Machines" |
There was a problem hiding this comment.
I'm curious about these. What is the idea behind them?
There was a problem hiding this comment.
I didn't want to have to vsce package install manually on my local machine and across the other machines.
I modified sync to support vsce package.json detection at the top level. so you can sync inside multi-build and it will detect the vsce and install it and reload the window, and post the message to reload the window...so that the other code windows open on the machine update their running plugin.
the multiBuild.updateAndInstall is a direct way to do it without the prompts and not via a sync.
multiBuild.broadcastUpdateAndInstall is the same idea, a way to directly broadcast to everyone that they should pull, package, and install.
they are implemented with the terminal and have timeouts and it bothers me; using direct invocation didn't provide any feedback so I think a timeout is OK and I guess I adjust it as runtime changes.
I will get to this as soon as I can; I'm trying to solve another issue and I can't put it down quite yet. If you get to this before I do, welcome to change it to suite your preferences.
I like the statubar version being there. I would like it to allow you to disconnect/disable/configure the plugin too.
There was a problem hiding this comment.
I'm trying to understand the rationale of developing through packaged versions, rather than running through the dev env on each machine. Normally when developing an extension you'd open the extension project in VS Code run npm run watch and hit F5 to open an instance with the extension running. Debugging the packaged version seems like quite a painful DX to me since you can't attach a debugger and you have to do everything through print statements.
However, [and I think this is a different problem that looks similar] outside of development, when transitioning back to being a user, I am finding it quite painful switching to the release version of the extension as it then has to be manually installed on each computer (as it's not on the marketplace yet). However, this problem is already solved by the VS Code Extension Marketplace and syncing your configs through Settings Sync.
Edit: Related to #28
There was a problem hiding this comment.
When developing the extension; being able to sync and build and install across all the machines is very helpful. I made sync support this, I added a local only method, and I am still trying to make other top level commands. i.e. the reload window functionality I was trying to find. If this doesn't go that's fine, but it was a serious help in testing the extension across my machines.
