GNU bug report logs - #41955
28.0.50; Monorepos and project.el

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Theodor Thornhill <theo <at> thornhill.no>, 41955 <at> debbugs.gnu.org
Cc: João Távora <joaotavora <at> gmail.com>
Subject: bug#41955: 28.0.50; Monorepos and project.el
Date: Sun, 21 Jun 2020 04:48:09 +0300

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)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.