Support for Yarn PnP

[ramblehead]

I have been playing with Yarn PnP support in tide-mode for a while:
ananthakumaran/tide#388

Recently, I have been trying lsp-mode with typescript in an attempt to unify my "Emacs IDE" configurations - as I am already using lsp mode with C++ (clangd).

Most my typescript repositories are Yarn 3 (recently upgraded from Yarn 2). The issues lsp-mode has when it comes to Yarn PnP support (zip'ed packages) are similar to tide-mode:

• Yarn PnP virtual paths are not resolved in xref jumps and in eldoc hints.
• tide-mode (Emacs really) is trying to open files in archives using TRAMP mode which is not perfect with archives handling (in my experience at least).

I wrote a small package that patches tide-mode to solve the above-mentioned issues. It was recently modified to work with lsp-mode:
https://github.com/ramblehead/.emacs.d/blob/master/lisp/yarn-pnp.el

yarn-pnp.el package can be loaded after or before tide or lsp as the following:

(require 'yarn-pnp)

(yarn-pnp-tide-enable) ; for tide
;; or
(yarn-pnp-lsp-enable) ; for lsp

I am not publishing this package as it relies on advice-add hacks and it may break if advised upstream functions change. Those hacks solve two Yarn PnP issues - resolving yarn virtual paths and opening zip package files with arc-mode instead of default tramp.

I am not sure if solving Yarn-PnP -- specific issues should be done in tide or lsp code. To me it seems a bit out-of-scope for those projects. Yarn-PnP virtual files schema has changed recently when upgrading from version 2 to version 3 and required corresponding changes in Emacs - it might change again. Also, some users may still prefer tramp instead of arc-mode (or something else). Should we instead add hooks into tide, lsp and eglot that can be used by other packages such as yarn-pnp.el to:

• filter xref paths (in case if they are virtual);
• open files (in case if they are inside archives);
• filter eldoc messages (is case if they contain virtual path as a substring)?

If such hooks can be added, then yarn-pnp.el can be refactored into a stable yarn pnp solution instead of relying on advice-add.

P. S. The following is my reference Yarn 3 (modified initial next.js app) repository that can be used to test and debug yarn-pnp.el:
https://gitlab.com/ogorod/next-app-rh

[yyoncho]

Some language servers provide virtual paths and then they provide a method to retrieve the actual content. For example, java language server returns files in jar archives. Also, the clients can return so-called path transformers path->uri-fn and path->uri-fn which can be used for handling such cases. I don't mind adding such handlers client side but generally, the logic for extracting the file content from the zip should reside in the server to be shared across the clients.

[ramblehead]

@yyoncho thank you for your reply and the ideas. I am glad you are not against supporting yarn-pnp directly from lsp-mode!

I did not realise that "virtual paths" are used in other language servers. I will take a look at path transformers - need to dig a bit more into lsp-mode architecture.

With archives. In my patch, the archives detection is already generalised to use type header instead of file extension, and to extract any archive supported by arc-mode - not just zip. It is a good point that it should be shared across lsp clients - or, possibly, across the whole Emacs? Would need to check how Emacs finds that archives should be handled by TRAMP - there might be an easy entry point (hook?) that can be intercepted to replace TRAPM by arc-mode under certain conditions...