Use unified-engine

[remcohaszing]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)
• If applicable, I’ve added docs and tests

Description of changes

This draft uses unified-engine to process documents. The old code has been left intact for now. The new code also uses ESM and JSDoc type annotations.

Closes #11

[remcohaszing]

And a screenshot to show what it looks like now with vim-lsp. :)

[remcohaszing]

The manual creation of connection and document is necessary for testing purposes, but it may be removed for a public interface.

Now that I have a better idea of how this should work, I can think of 2 options for a public interface. Personally I prefer option 2.

Option 1: Provide a CLI for the unified language server

This means the end user will have to specify some options.

unified-language-server --prefix remark --plugin remark-parse --plugin remark-stringify --stdio

Option 2: Provide a NodeJS API

This means for every unified ecosystem a language server needs to be created. This is similar to unified-args.

Creating remark-language-server will be as simple as:

import {initUnifiedLanguageServer} from 'unified-language-server'

initUnifiedLanguageServer('remark', [
  'remark-parse',
  'remark-stringify'
])

End users will simply run:

remark-language-server --stdio

[ChristianMurphy]

There two options aren't strictly mutually exclusive.
If we start with option 2, a NodeJS API, we could build option 1 a CLI on top of that later if wanted.

[wooorm]

How are language servers used? Who is using this already, and how (or what projects do similar stuff that should switch to using this project?)

[ChristianMurphy]

How are language servers used?

I mostly used language servers through VSCode.
Which wraps usually wraps the language server as a VSCode extension.
I'm not as familiar with how it is used with other editors.

what projects do similar stuff that should switch to using this project?

I think there are some MDX language servers which could be migrated to use this.
And the remark, and incoming rehype (retextjs/retext#57), language servers would likely need to be updated to leverage the new structure/features

[remcohaszing]

Many editors support this using a minimal amount of code (if any). Based on this language server, it should be fairly straight forward to integrate unified into any of those editors.

Language servers provide many features, but the ones that make sense for unified are linting and formatting.

My goal is to make vscode-remark use this language server. A similar plugin could be created for rehype, redot, and possibly others.

Based on the fact that unified-engine-atom still uses CJS, it’s outdated. That project can probably be discontinued in favor of plugins based on this language server.

[aecepoglu]

I like fewer things to exist so I'd vote for there being one executable that can be edited to fit multiple roles. One language-server that can both to plain-text, HTML, markdown, asciidoc, .. with the help of plugins.

[remcohaszing]

Option 3: Support language server settings

Language servers support configuration options. This can be leveraged to configure unified-engine.

if (executable('unified-language-server'))
  au User lsp_setup call lsp#register_server({
  \ 'name': 'remark',
  \ 'cmd': {server_info->['unified-language-server', '--stdio']},
  \ 'allowlist': ['markdown'],
  \ 'config': {
  \   'defaultSource': 'remark',
  \   'ignoreName': '.remarkignore',
  \   'packageField': '.remarkConfig',
  \   'pluginPrefix': 'remark',
  \   'plugins': ['remark-parse', 'remark-stringify'],
  \   'rcName': '.remarkrc'
  \ })
endif

---

I still think option 2 is the way to go. This requires no additional configuration for end users, making it the simplest to use and leaving the least room for users to misconfigure it.

However, option 3 would be nice for some use cases. For example debugging unified-language-server or fiddling with a new ecosysem based on unified.

These options don’t have to exclude each other.

[remcohaszing]

I couldn’t get loading configuration to work, so I suggest to create an issue for it so it can be implemented later.

[aecepoglu]

Well this seems like a major change :D

I am not keeping up to date with what's happening with unifiedJS or the language server. Ideally my code would have been modifiable enough that not the entirety of it would change :) but I encourage any amount of change including those beyond 99%

If anyone wants their name to be in the author field because they did more work than the original, you're welcome to change it as far as I'm concerned.

👍

[wooorm]

Some style things, but 👍 on the code

[ChristianMurphy]

Thanks @remcohaszing!
Added a few questions below.

[wooorm]

(one comment was accidentally in a PR review, see above)

[wooorm]

• Is unified-language-server-0.3.0.tgz supposed to be checked in?

[wooorm]

@remcohaszing Btw, reading the example code, shouldn’t remark-parse, remark-stringify, other other things be added to dependencies in package.json perhaps?

[remcohaszing]

@remcohaszing Btw, reading the example code, shouldn’t remark-parse, remark-stringify, other other things be added to dependencies in package.json perhaps?

No. These will be loaded from the user’s local workspace.