Initially, I tried installing prettier and using its JavaScript API (so that the extension wouldn't even be needed), but I faced issues bundling it with ESBuild. I replaced ESBuild with Rollup and after some config hacks it bundled successfully, but then I faced the most important issue: editing the document in the middleware (even before requesting from the LSP server) causes VS Code to cancel the formatting request, requiring the user to trigger it again.
The best thing to do here is to format the document (in-memory, not on-disk) and then diff the output with the original input and transform that "diff" to LSP's TextEdits, and then merge them with the array returned from our formatter, but that would have been unnecessarily complicated.
The only way around this was to format with Prettier after the server's edits were already applied by VS Code, which means using the ugly setTimeout. Also, I went back on the "not requiring the Prettier extension" part because that felt like forcing Prettier on all users, so instead I decided to check if the prettier.enable setting is true, and then simply invoke command from the Prettier extension itself.
Shortcomings
Since the document is edited (by Prettier) after the requested formatting is complete, it will be left in a dirty state. This is a minor annoyance that is only relevant if the user had the "format on save" option turned on and formatted by saving. I tried working around it by adding vscode.commands.executeCommand("workbench.action.files.saveWithoutFormatting"); after Prettier completes, but that will always force saving even if the user didn't request formatting through saving, which is somewhat intrusive.
This PR implements a hack that would call Prettier's format command after our own formatter completes execution. It also includes a minor refactor and updating deps, but the only relevant commit is https://github.com/rzk-lang/vscode-rzk/commit/8096181a6de0ca07ce3f8b6f28fbcd5db5a201b1.
Long story
Initially, I tried installing
prettierand using its JavaScript API (so that the extension wouldn't even be needed), but I faced issues bundling it with ESBuild. I replaced ESBuild with Rollup and after some config hacks it bundled successfully, but then I faced the most important issue: editing the document in the middleware (even before requesting from the LSP server) causes VS Code to cancel the formatting request, requiring the user to trigger it again. The best thing to do here is to format the document (in-memory, not on-disk) and then diff the output with the original input and transform that "diff" to LSP'sTextEdits, and then merge them with the array returned from our formatter, but that would have been unnecessarily complicated. The only way around this was to format with Prettier after the server's edits were already applied by VS Code, which means using the uglysetTimeout. Also, I went back on the "not requiring the Prettier extension" part because that felt like forcing Prettier on all users, so instead I decided to check if theprettier.enablesetting istrue, and then simply invoke command from the Prettier extension itself.Shortcomings
Since the document is edited (by Prettier) after the requested formatting is complete, it will be left in a dirty state. This is a minor annoyance that is only relevant if the user had the "format on save" option turned on and formatted by saving. I tried working around it by adding
vscode.commands.executeCommand("workbench.action.files.saveWithoutFormatting");after Prettier completes, but that will always force saving even if the user didn't request formatting through saving, which is somewhat intrusive.