Re: eglot-tests fail for emacs-31 branch

Michael Albinus <[email protected]> writes:


>>> emba environment; see admin/notes/emba.
>>
> e2ff4dbf3db5 (Michael Albinus     2023-03-25  76)
> 13a4cd5ed1ed (Michael Albinus     2025-06-08  77) RUN npm install -g typescript-language-server typescript
> 13a4cd5ed1ed (Michael Albinus     2025-06-08  78) RUN npm install -g
> vscode-json-languageserver

Right, so it was you :-) I didn't have the code handy.  Anyway, to be
clear, I am thankful for this work: this means Eglot is routinely being
tested more thoroughly than it otherwise would without those lines,
which is a good thing.

>> moving target: likely the "typescript-language-server" package now has
>> different requirements which somehow don't play well with Debian Trixie.
>> So whoever is the npm connoisseur around these parts should try to "pin"
>> those installations to a known good version.
>
> If you speak about me: I'm not a connaisseur of npm, typescript, or
> typescript-language-server.

I was talking in general (and in jest, I didn't know it had been you).

Anyway, I suggest changing that lines to

RUN npm install -g [email protected] [email protected]
RUN npm install -g [email protected]

> However, pinning a given package version is not the solution.  On
> emba, we try to run tests in a Debian environment an Emacs user will
> see. If this doesn't work, we must fix it, or document what to do.

I heartily disagree with you on this (philosophical?) point.  Probably
one of the reasons we use Debian Trixie and not, say, a rolling-release
Arch linux, is precisely that it always give us stable version of the
software surrounding ours, so that the "fixed" in "fixture" can be
upheld.  So if we use 'npm' in addition to 'apt' as a package
installation aid, we must make sure it behaves like apt.

In practice, and concretely to the Eglot failure in question, I am more
than happy if the signal is: "does Eglot currently work with _some known
good version_ of typescript-language-server"?  That's because Eglot can
be combined with so many other things, that I know with almost 100%
certainty that, out there, there is some combination of language server
+ OS + myriad other thing that makes Eglot fail.

Anyway, I'll see if I find the time to try these changes on my own, I
started building a new podman emba thing yesterday but I'm rusty and it
was taking a long while to compile, so I would be very thankful if you
could try those `npm install -g` for me, interactively, in your
up-to-date local emba and then re-run `make -C test eglot-tests`.  If
they pass there's a good change that it's a good change to commit to the
Dockerfile.  If you don't agree, just remove those two lines altogether.
It'll fix the failures, of course (and I'll lose the signal, but that's
not dramatic).  Up to you.

Thanks again,
João