VSCode extension re-implementation

[Loosetooth]

@tonious Creating this topic to discuss the VSCode extension revamp.

Basic features of the extension:

1. can somehow run a js bundle that generates manifoldCAD compatible script output
2. output is visualized
3. logs are shown
4. there is a download button

The flow we were imagining:

1. each manifoldcad script has a package.json file (mainly for dependencies now, and other stuff in the future)
2. there is a bundle script in the package.json that is run via an npm/pnpm/etc command
3. the resulting bundle is picked up by the vscode extension, and is executed (some kind of watch?)
4. the output is visualized

I think this is the most basic way of doing it, and I guess this should keep the vscode extension as simple as possible.
What do you think?
Let me know if you have any remarks or other ideas.

[tonious]

I have another proposal:

1. Each manifoldcad script has a package.json that must include manifold-3d.
2. npm install must be called in the workspace. I.e.: Packages are local. The extension can even trigger this, if necessary.
3. The extension can use the entry point specified to call manifold-cli --watch or maybe a dedicated script like manifold-live. Naming things is hard.
   3a. manifold-cli builds the model, but does not exit.
   3b. manifold-cli waits for changes¹
   3c. manifold-cli emits² log messages, errors, and lifecycle notifications. This could be how the extension knows which file to display, for example.
4. The extension listens for events, and updates the log or webview as appropriate.
   4a. The extension may have to kill/restart manifold-cli if it hangs.

This way the extension doesn't have to know or care about bundling or evaluating actually works. It just has to be able to trigger the process and wait for the results. Additionally, keeping manifold in memory means that successive builds are fast. Instantiating esbuild takes several seconds, but after that builds are next to instantaneous.

Footnotes

1. This could be either a filesystem watch, or a message from the extension to the cli. I know the previous extension piggybacks on the file-saved event. I'm pretty sure there's a workspace changed event in VS code. ↩

2. I'm not sure how best to implement this. It could be anything from named pipes to a language server. ↩

[Loosetooth]

Thanks @tonious, much better worded than me at 1:30 am :)

Each manifoldcad script has a package.json that must include manifold-3d.

100% agree, this is also how we do it in CADit atm. This also allows specifying exact manifold-3d versions. (I guess ideally our vscode extension should be compatible with all of them, but let's just focus on getting it running for now.)

npm install must be called in the workspace. I.e.: Packages are local. The extension can even trigger this, if necessary.

Agree.
I wonder though if vscode extensions can run arbitrary commands on the user's system. And even then, we should be careful here, as different package managers could be used for the current vscode workspace / repo that is opened.

The extension can use the entry point specified to call manifold-cli --watch or maybe a dedicated script like manifold-live. Naming things is hard.

Using the manifold-cli is fine to me, if we only want to preview the output model itself.
That's actually something I didn't think of yet.

Bundling (and running it inside the extension webview) would offer more flexibility if we want:

1. access to browser apis (closer to browser-based manifoldcad)
2. script parameters with menu, and injecting params in an exported function
3. extra features we do not think of yet

Just some thoughts.
Let me know if I misunderstand anything.

[tonious]

I wonder though if vscode extensions can run arbitrary commands on the user's system.

I'm not sure about arbitrary commands... We might be limited to the workspace. That said, we could always do this the other way. Have the user run manifold-live. The extension could watch for named fifos or dotfiles or something.

And even then, we should be careful here, as different package managers could be used for the current vscode workspace / repo that is opened.

Oh, good point. So short term, I think we require users to run their own package manager. Longer term, we can probably check for known package managers in the dependencies list, as well as their lock files.

Bundling (and running it inside the extension webview) would offer more flexibility if we want:

1. access to browser apis (closer to browser-based manifoldcad)

I'd rather keep the worker as platform agnostic as possible. Scripts only get a subset of the browser surface anyhow, as they are sandboxed pretty tightly and run in a web worker.

That said, I'm not above using polyfills or bundler tricks to make scripts behave as if they are in a browser, like import.meta.url.

2. script parameters with menu, and injecting params in an exported function

This is interesting. I think it could also be handled through messaging, though. manifold-live can pass its schema forwards, and then the extension passes parameters back. And I'd have to implement that messaging anyhow to make it work in the browser.

Silly thought -- it'd be cool to use something like json forms or react-jsonchema-form to describe parameters for a builder.

3. extra features we do not think of yet

I guess I technically can't argue this one 😂

[tonious]

#1536 makes some space in bindings/wasm/examples/ for this.