[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41955: 28.0.50; Monorepos and project.el
From: |
Dmitry Gutov |
Subject: |
bug#41955: 28.0.50; Monorepos and project.el |
Date: |
Sun, 21 Jun 2020 04:48:09 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 |
On 19.06.2020 23:42, Theodor Thornhill wrote:
At work I've had the following issue. Assume we have some sort of
gigarepo, like this maybe:
gigarepo/
├── clients
│ ├── client1
│ ├── client2
│ ├── client3
│ └── client4
└── services
├── service1
├── service2
├── service3
└── service4
The services are made in different languages, say, some in c#, f#, java -
as are clients, some are Typescript projects, some are JS etc etc.
Everything is rooted in a ".git" in "gigarepo/", and there are no
submodules or any fancyness.
As project.el works now, there are several issues arising. I'll just
note them down here, and probably split things up later, if that is ok.
Thank you for the report and the description. Before moving on to more
complete solutions, here are some initial comments:
* Lsp server/client
In most of the projects, the lsp servers are indexing from what they
consider root. Typically a tsconfig.json, elm.json etc. They get
confused, eglot a bit more than lsp-mode (it has its own root finding
algorithm). What happens is they look in root (gigarepo/), and it has
no executable for lsp-server. One solution is then to install the
server in root, but then it indexes the whole thing, and gets super
slow, and indexes a lot of unrelated stuff (I'm not even working on
client 2-4.)
I think Eglot is wrong in simply defaulting to project-root, without
looking for tsconfig.json, etc. It would be pretty easy to implement,
and would bring it closer to VS Code's behavior in this aspect (I think).
But that would require it to maintain a list of such files.
* Buffer switching
Lets say several of the clients uses a module called AuthService.ts.
If I'm working on several of these projects you get a lot of identical
files, so it is a bit hit and miss.
Uniquify should help, but yeah, it sounds like a pain point indeed.
* Grepping
This one was the worst for me, since grepping was very slow given the
size of the project, and grepping loads of unrelated files returns a
lot of noise.
This is just a small step, but have you tried the patch here (with rg)?
https://lists.gnu.org/archive/html/emacs-devel/2020-06/msg00547.html
What would be nice is to be able to get the benefits of the vc-dir
version of project.el, but not having to "git init" inside the child
projects. More specifically, to be able to choose "project context",
one as the closest project-root and one as the gigarepo project-root.
Here's some code based on yours.
Also rough and unofficial, but should hopefully be faster.
(defvar project-root-markers
'("package.json"
"tsconfig.json"
"jsconfig.json"
"elm.json"
"*.sln")
"Files or directories that indicate the root of a project.")
;; Probably better in .dir-locals.el.
(setq project-vc-ignores
'("node_modules"
"target"
"build"
"package-lock.json"
"elm-stuff"))
(defun project-find-nomono (dir)
(let ((root
(locate-dominating-file
dir
(lambda (d)
(let ((default-directory d))
(seq-some #'file-expand-wildcards
project-root-markers))))))
(when (and root
(ignore-errors
(vc-responsible-backend root)))
(cons 'vc root))))
(add-hook 'project-find-functions #'project-find-nomono)
bug#41955: 28.0.50; Monorepos and project.el, Juri Linkov, 2020/06/20
bug#41955: 28.0.50; Monorepos and project.el,
Dmitry Gutov <=