IDE integration: existing VS Code rewrite

[ivangsa]

I'm moving this issue #8 for discussion here:

---

Hi. I rewrote the Spectral VS Code extension as a small, direct integration with Spectral: no LSP, authenticated/custom loaders, and VS Code Web support. We already use it internally.

I offered it to stoplightio/vscode-spectral and got no response. I would rather put this into OpenLint.

I can start as maintainer of the IDE integration and help land it as part of the toolbox. I am not looking to own it forever, and I do not want this to stay a solo effort. If others want to join on the editor side, that is the outcome I am aiming for.

If IDE support is going into the first roadmap, I can share the repo and we can decide how it should live here.

---

stoplightio/vscode-spectral#278
stoplightio/spectral#3045

[dvh]

Nice! In the original issue, you mentioned that this is no LSP for different reasons. But the benefit of an LSP is that it's IDE-agnostic. I think we should provide only one IDE extension in order to make it maintainable, so if we have to choose between VSCode-only or LSP my preference would be LSP.

However, a lot of people are complaining about the current VSCode extension, while at the same time a lot of people are using VSCode. So, is it possible to rewrite this to an LSP approach afterwards? If the answer is yes, we could publish your extension as a "v1" of the "OpenLint IDE Extension" (which currently only supports VSCode) while upgrading to "v2" in the future could use LSP in order to support more IDEs. That would make a lot of people happy already.

[ivangsa]

In short, the LSP aproach was waaay over engineering (for reasons that I dont know). The new extension is very light in runtime and in LOC, just calling the js library for getting linting errors

For other non-nodejs you can not do this, but that is another theme alltogether

[ivangsa]

OpenLint VSCode Extension is here: https://github.com/ivangsa/openlint-vscode
I fully own the (very small) codebase.
Remaining work is prepare the pipelines to publish to vscode marketplace and open-vsx.org

[kinlane]

I will test drive and provide feedback.

[kinlane]

Picking this up after Office Hours #5, where the VS Code extension and a language server came up as priorities to work on in tandem. A proposal to react to:

1. Ship Ivan's extension as v1. People are waiting, it runs the real OpenLint engine, and this is what @dvh suggested above. It needs moving into the org, the published @openlint/* packages, Marketplace and Open VSX publishing, and tests. @ivangsa, in the meantime could you attach a packaged .vsix to a release? I tried running it from source and couldn't get the debug launch working, and a .vsix would let people test it without a build.
2. Build a small language server around the OpenLint engine, so every editor reports what the CLI reports. There's an early prototype and plan at openlint/language-server: diagnostics only, with a test that its results match the CLI's on one fixture, and not yet tried in a real editor. Extension v2 becomes a client of it. @ivangsa, you chose no LSP for good reasons: authenticated loaders and VS Code Web. Would a browser-transport server and secrets passed from the client cover them, or is there something else we'd lose?
3. Connect with other language server work. suspect by Luke Parke has navigation, rename and hover for OpenAPI, Arazzo and Overlay, on its own Rust linter. I'd love to see it run against the conformance suite, and to explore how the two work side by side.

One rule I'd like us to work from: anything calling itself OpenLint in an editor runs the OpenLint engine or passes the conformance suite, so the editor reports what CI reports. That's open to any engine in any language, and other servers can partner on navigation and rename in the meantime.

Dimitri and Joost, you offered to look at the language server. Is this a shape you'd want to work on with Ivan?

[ivangsa]

Released a .vsix https://github.com/ivangsa/openlint-vscode/releases/tag/v0.0.1

The reason it didnt build on your side is bc I had a sibling checkout build, until openlint were available in npm-registry, that is fixed now

Regarding LSP, because it would be required for other platforms like IntelliJ, NeoVim, Zed... then using it in vscode would bring some isolation to the runtime, but in vscode is not essential

Creating an LSP server could be something mostly mechanical and AFK on this day an age..

I would test that the current implementation do not cause performance issues on the UI with some big rulesets, and I'm happy to create a PR to an official repo, but feel free to choose any other route, this is a very small codebase still

[ivangsa]

this new release has debug statements for understanding performance:
https://github.com/ivangsa/openlint-vscode/releases/tag/v0.1.0