Re: eglot-tests fail for emacs-31 branch

Hi again, Michael

Michael Albinus <[email protected]> writes:

>>> 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
>>
>> Anyway, I suggest changing that lines to
>>
>> RUN npm install -g [email protected] [email protected]
>> RUN npm install -g [email protected]

> /usr/local/lib
> +-- [email protected]
> +-- [email protected]
> `-- [email protected]
>
>
> And now, running 'make -C test eglot-tests' passes all tests. Good.

Good, indeed.

>>> 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.
>
> I would pretty much prefer apt over npm. But there are no respective apt
> packages in Debian. There are only snap packages. And using snap doesn't
> work in containers. See the comments in Dockerfile.emba about.

There are alternatives to npm, I think, but they probably don't offer
substantive improvements in this regard.

> And even if it would be possible to use snap inside a container, it
> would install the same versions like npm (tested with my Fedora 44
> laptop):
>
> # snap install typescript-language-server
> typescript-language-server 5.3.0 from Alex Murray (alexmurray✪) installed
> # snap install vscode-json-languageserver
> vscode-json-languageserver 1.3.4 from Alex Murray (alexmurray✪) installed
>
> So yes, these versions of typescript-language-server and
> vscode-json-languageserver should be supported. Emacs 31 users will
> see them.

Here's the thing: probably many other version -- even the most recent
versions that broke EMA -- are supported as long as you configure them
correctly.  It's just EMBA is not doing that (and shouldn't have to
worry about that, IMO).

>> 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.
>
> Sure, we can pin versions to be tested on emba. But that's a moving
> target.

Is it?  Isn't it the opposite.  I think the pinning I suggested will
work for a good long while, if not "forever".

> I would appreciate if we could have this documented, at
> least. Something like a comment in eglot.el, "tested with xxx language
> server 123". And then we need to establish a policy, how these
> versions can be changed over the time.

I think that's too complex and brings little value.  There are hundreds
of language servers in various variations and versions . I appreciate
that Eglot is tested routinely on EMBA with a fair number of servers
including this now-slightly-older version of typescript-language-server.
But that's not the only place I run test Eglot (in fact it's not my
primary place).  For example, in my laptop I have 5.3.0 but it somehow
is functional, and if it ever becomes non-functional with that bizarre
error I can probably fix it here.  In my other laptop I have probably an
even older version.  The point is that Eglot should be testable with
whatever _functional_ version of typescript-language-server one has
lying around.  It shouldn't require a specific version in
eglot-tests.el, that is fragile.

Bottom line is that if EMBA wants to help in test Eglot in this
particular regard, then all it has to do is have a functional version of
this server lying around.  The npm version pinning I suggested is _a_
way to do that, perhaps the simplest way, and you've confirmed it works.
But if you prefer finding the server in apt or snap or the newest JS
package manager du jour I have no objections of course.

>> If they pass there's a good change that it's a good change to commit
>> to the Dockerfile.
>
> I will do once we have agreed how to handle this version pinning in general.

OK.

> Now that we know it isn't a showstopper for Emacs 31.1, I can live with
> this error for a while. And it would be great if you could find a
> solution in eglot.el, or at least a condition for skipping the two tests
> in eglot-tests.el.

I hope I've explained above why that is counter-productive: such a
condition would be complex to setup, fragile and needlessly cripple the
tests for other functional non-EMBA typescript-language-server
installations.

> Emacs users will report about this error in the
> future (I'm sure),

They might, but I wouldn't be surprised if they don't.  The LSP server
landscape is vast and fragile and people sort of expect this breakage.
Especially the JS folks, this is probably old news to them, they probaly
use a project-specific server, not a rolling global installation (much
like the Python folks likely do with virtual envs).

> and we should be happy that we can reproduc the error
> locally. So we have a chance to fix.

I really wouldn't be happy :-), just indifferent.  There would be
nothing to fix, and nothing interesting to learn.  This particular
problem ("the server is here but typescript not found") is a failure by
the user and typescript-language-server (chiefly the latter, probably)
to set things up correctly.  That's completely outside the realm of
Eglot, so my answer would be say sorry and close the bug.

João