Replies: 1 comment 1 reply
-
|
Can you start simple and specify what issues do you see when you open a file without workspace root set? tsconfig.json shouldn't be technically needed (certain defaults will be used in that case) and there shouldn't be any errors. Try to provide a reproduction that will allow us to understand whether what you are seeing is specific to you (or neovim). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. No workspace is set when i open a file that has no tsconfig.json in its parent filesystem tree. What happens here is expected behavior, but it produces errors because it cannot find the global dependencies I have configured for these standalone scripts to use, which are installed under What I'm hoping to achieve is a way to configure its behavior to "treat" this file as being in there for the purposes of resolving dependencies and such. My concern is that from what I've found so far poking around in tsserver source code, even once I figure out how to configure the workspace from the editor side, it looks like tsserver has code internally that resolves workspace from the path of the opened file. It leads me to another idea for a hack, which is maybe I can detect these standalone files and temporarily relocate them into this directory, allow the editor to do its editing there (in which case the LSP doesn't need to be tricked/enhanced to work as intended), and synchronize it back to its original place afterward... |
Beta Was this translation helpful? Give feedback.
-
I'm using tsserver with the neovim LSP client. I have not been able to figure out how to properly configure tsserver from my editor (to set the workspace path, if that is even possible), but regardless of that, I'm able to test by surgically modifying tsserver's runtime code in order to validate my hypothesis.
I wrote up what I have tried so far in here: pmizio/typescript-tools.nvim#259
Now what I have found is even if I override the value of
this.workspaceRootin the call tothis.tsClient.startincli.mjs, it does not change behavior but if I override both that and the return value ofgetProjectRootPath, e.g.:I apparently was able to force tsserver to find the global dependencies like this.
Obviously I can't leave the code hardcoded like this, and I also cannot grok anywhere close to enough of this code to make sense of what the intention and interpretation of the tsserver config is meant to be, but something tells me based on this experiment that the config is ill-defined if the open file is ever found not to be in the projectRootPath that's been determined.
That assumption is perhaps a reasonable one. But given how well
tsxworks I wanted to explore a world in which we can run typescript independently of any project or workspace structure, and it seems impossible to do that with tsserver as it exists right now.Can anyone confirm that my hunch is correct on this? If so what architectural changes would be needed to address this use case? Since I seem to have been able to hack it to work by hard coding some root path values in the code maybe it's not a lot of work.
Beta Was this translation helpful? Give feedback.
All reactions