solargraph
solargraph copied to clipboard
castwide
Issue loading required files in bundler, under LSP in Emacs
I've written out my full issue in the lsp-mode repo: https://github.com/emacs-lsp/lsp-mode/issues/2646 But I'll summarize here as well. Using solargraph as an LSP backend in emacs, I can't get it to grok files that I require that are outside of the workspace tree. Files in gem dependencies that are declared in my Gemfile.
I'm allegedly running solargraph under bundler. I know very little about that setup but I can perform any debugging step you think might be helpful.
I'm having the same issue. I've got a project with a Gemfile with a gem specified there, and I'm trying to require that gem in a file, but the require_not_found reporter is kicking in. I'm using coc-solargraph in Vim, but it (allegedly) has a way to specify solargraph.useBundler as mentioned here.
Are there any known issues with Bundler?
There are two possible causes here. Solargraph loads the yardocs for external gems instead of trying to parse every dependency's code. You can run yard gems to ensure that all your gems have yardocs. More information: https://solargraph.org/guides/yard
Solargraph also can't detect yardocs in gems loaded from paths. This is the issue with the example project from emacs-lsp/lsp-mode#2646. If you load solartest/one as a workspace, it doesn't have access to solartest/thelib. If you load solartest as a workspace, however, both directories get mapped. Unfortunately, there isn't currently a good solution for loading a gem from a path in a different directory.
If this helps advance this issue, I was having the same problem as described by the author and running bundle exec yard gems solved it for me. My setup is Doom Emacs with lsp-mode and solargraph.
I now realize that this is documented in https://github.com/castwide/solargraph#solargraph-and-bundler. Sadly search engines don't redirect there when searching for the error message "Required path could not be resolved".
@castwide
Solargraph also can't detect yardocs in gems loaded from paths Ok, thanks. I'm curious - why is this the case? is there any room for potential improvements here? if you could point me in a direction i might be able to take a crack at it.