Open aljazerzen opened 1 month ago
You can download plugins manually and reference them locally. It's convenient for Wasm plugins, but follow https://github.com/dprint/dprint/issues/818 for details on how to make process plugins more conveient to setup. Right now it's a bit of a pain to setup manually because you need to create the .json
file and have that reference a local zip file. Something better needs to be done there.
On security, the Wasm plugins run sandboxed with no access to the network or file system and process plugins require specifying a checksum. The CI pipelines that build the process plugins output the checksums so you can trace it back to the CI run.
You can download plugins manually and reference them locally.
Ok, that's nice. Would it be possible to simplify that path to be able to reference .wasm/.zip files or executable files directly?
the Wasm plugins run sandboxed
Yes, but the process plugins do not. So they could potentially access any files accessible to the user.
I'll probably opt for running dprint in a firejail.
First of all, I love this project. Over the weekend I started a project that is basically the same thing as dprint and when looking for a TOML formatter, I found dprint!
I've been looking around to see how it differs from what I imagined and there is one core difference: dprint is accessing network. It is downloading and running wasm plugins, binaries and checking for updates.
This has a few implications:
dprint --help
takes a few seconds.In ideal scenario, dprint would run completely offline, and leave the problem of software distribution to tools dedicated for that. In my case, I'd use nix flakes + direnv which would build and enter the project environment, which would contain all necessary tools: dprint, dprint-plugin-exec, rustfmt and all other needed .wasm plugins.
One way to accomplish that would be another implementation of dprint CLI that would be able to use the same plugins.
I know that this is a major shift in paradigm I'm asking for, so would be willing to help.