feat: add npm run try for interactive extension testing

[markkohdev]

Description

Sorry @cbandera, here's another quick one for ya 😅 This was helpful when I was debugging some of the logging and querying changes.

• Adds a new npm run try script that packages the extension, downloads a local VS Code instance, installs the .vsix, and opens a disposable copy of the test Bazel workspace for interactive experimentation.
• The launched VS Code uses isolated user-data and extensions directories under .vscode-test/, so it doesn't affect the developer's normal VS Code installation.
• The test workspace is copied to .vscode-test/try-workspace/ (skipping Bazel output symlinks) so edits made during experimentation don't modify source-controlled files.
• Documents the new workflow in CONTRIBUTING.md.

Related Issue

N/A

Testing

• Run npm run try and verify VS Code launches with the extension active and the test workspace open.
• Make edits in the launched VS Code and confirm git status shows no changes to test/bazel_workspace/.
• Run npm run clean and confirm .vscode-test/ is removed.
• Run npm run try a second time and verify the workspace copy is refreshed (previous edits are gone).

Checklist

• Code follows the project's style guidelines (prettier/eslint)
• Commit messages follow Conventional Commit conventions
• Tests pass locally (npm run test)

[cbandera]

@markkohdev thank you for yet another PR. Can you outline how this functionality differs from using the VSCode Launch Config (F5)?
Or maybe, are you aware of the launch config?
Without having tested your change yet, it sounds very similar in functionality.

[markkohdev]

@markkohdev thank you for yet another PR. Can you outline how this functionality differs from using the VSCode Launch Config (F5)? Or maybe, are you aware of the launch config? Without having tested your change yet, it sounds very similar in functionality.

@cbandera great question! I actually didn't know about the launch configs when I originally made this PR but I did find them yesterday. That said, there's a couple differences between this functionality and the launch configs:

---

Local IDE vs isolated VSCode instance
The launch configs run in your current local IDE vs the try runs in an isolated vscode instance. Your local IDE may or may be any VScode derivative (Cursor, Windsurf, etc) which may not be an IDE that we want to support with the extension. Additionally, you may have other extensions installed in your local IDE that may conflict with the Bazel extension in ways that we can't predict.

Empty Workspace vs Test Workspace
The launch configs will run a new window with no directories open which makes it difficult to immediately test what's happening. The try command first clones the test bazel workspace (in test/bazel_workspace) to a non-source-controlled directory and then launches the new vscode window with that test directory so you can play around with the files and whatnot without worrying about accidentally messing up the test files.

Packaging vs Source Code
The launch configs run the extension directly from source whereas the try command first packages the extension into a VSIX so that we can test any changes end-to-end (including changes to the packaging behavior).

Debugging
The try command doesn't have a debugger integration because it packages the extension. This would be good to have though if we can launch it directly from source into the isolated vscode!

---

Overall, both solutions are good to have. I think I can update this PR to have the best of both worlds though, with switchable options at the launch config level

[markkohdev]

@cbandera any thoughts on my last comment above?

[cbandera]

I was inclined to say that we need another launch entrypoint. But given your explanation I do see that it would be useful (especially for PRs like #561 ).
And I think it could even be integrated with the F5 entrypoints. E.g. via:

        {
            "name": "Launch Extension (Isolated Test)",
            "type": "node",
            "request": "launch",
            "program": "${workspaceFolder}/scripts/try-extension.js",
            "console": "integratedTerminal",
            "env": {
                "NODE_ENV": "development"
            }
        }

I am having a hard time to decide what the best name would be. try seems to not really capture the whole nature of it.
Some ideas are: sandboxed-deploy, isolated-launch, packaged-preview... but I haven't found a favorite. Does any of these resonate with you?

Finally: It doesn't work on WSL which means I can't test it at the moment. The reason is that on WSL you typically start the GUI instance installed on windows and simply connect to your WSL instance through the "remote" extensions of VSCode.
I will try to get a setup on linux again though to test this.

[cbandera]

BTW @cameron-martin do you know what the right copyright header is since the project moved to the linux foundation? Do we use copyright/license headers at all anymore?

[cameron-martin]

No idea. Maybe ask in the bazel slack?

[cbandera]

Do we need to / should we cleanup the userDataDir and extensionsDir as well?

[cbandera]

Tested it on native linux now and vscode doesn't start up either... :(