TypescriptGoToSourceDefinition failing

[sQVe]

Hello 👋🏼,

For certain projects I'm seeing failures to use the source definition mapping. I'm seeing the following issue:

Error executing vim.schedule lua callback: vim/shared.lua:0: Expected table, got nil                                                                                          
stack traceback:                                                                                                                                                              
        [C]: in function 'assert'                                                                                                                                             
        vim/shared.lua: in function 'tbl_isempty'                                                                                                                             
        .../site/pack/packer/opt/typescript.nvim/lua/typescript.lua:2679: in function 'handler'                                                                               
        /usr/share/nvim/runtime/lua/vim/lsp.lua:1390: in function ''                                                                                                          
        vim/_editor.lua: in function <vim/_editor.lua:0>                                                                                                                      
Press ENTER or type command to continue     

[roginfarrer]

I just installed the plugin, and I'm seeing the same error

[jose-elias-alvarez]

Can you try #38?

Edit: also, if you're able to tell me which dependency is causing this error for you (assuming it's public) I could make sure that our behavior matches VS Code's, since I haven't seen this issue in my own usage.

[sQVe]

@jose-elias-alvarez Going to soruce definiton on is here replicates it for me: https://github.com/sQVe/lika/blob/main/src/string.ts#L11

[sQVe]

@jose-elias-alvarez #38 solves it and outputs: LSP[tsserver] Go to Source Definition failed. Requires TypeScript 4.7+. instead.

[jose-elias-alvarez]

Great, thanks for confirming. That's also how VS Code behaves, so I think this is the right behavior.