-
Notifications
You must be signed in to change notification settings - Fork 40
Build LSP directly in destination so source maps are correct #749
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@juliasilge is this change safe for you? I wonder specifically if the action that builds the vsix installers will work under this change. |
Good point, I've checked that |
hmm that action was running automatically in #748 but here it didn't start. |
okay the GH actions were not watching over |
Do similar changes need to happen in https://github.com/quarto-dev/quarto/blob/main/.github/workflows/publish.yaml? There's references to apps/vscode there as well. |
I don't think so. We don't need to watch LSP files in that workflow and regarding build dependencies, the dependency of apps/vscode on apps/lsp is internally defined. There is a quarto/apps/vscode/package.json Line 1410 in a1513ef
This ensures Line 6 in a1513ef
turbo looks for dependencies, including internal ones, in each package.json file. Since quarto-lsp (the module name of apps/lsp/) is a dendency of apps/vscode, the build order is guaranteed.
I wonder if we're actually building apps/vscode twice, once in the prepublish step and once in the build step. 🤔 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took me a couple of tries to get it to work, but I did manage to set a breakpoint in the LSP with this PR.
How would you feel about adding something in README.md
or a new CONTRIBUTING.md
about how to get that set up?
I cannot tell if we are building apps/vscode
twice. 😬
3624d2f
to
e07fe28
Compare
* Build LSP directly in destination so source maps are correct * Fix LSP `outFiles` * Trigger workflows on LSP changes
We were building inside
apps/lsp/dist
, then copying over toapps/vscode/out/lsp
. But the source maps are relative so they were no longer pointing to the correct locations.Since this is a mono repo, I thought we could just directly build in the vscode's output directory.
With this change, we can set breakpoints inside the LSP. You'll first need to use the "Attach to LSP" launch action once the LSP process has been spawned.