Pull out generic LSP code into a new package?

[sgwilym]

Hey! I've recently released https://github.com/sgwilym/nova-deno, which contains a fair bit of code that I've more or less copied or pasted from this repo. So thank you, it's really been invaluable!

Given the universal utility of a lot of these utilities, how would you feel about working together to pull them out into a new module and make them a little more generic? I'm happy copy and pasting for now, but it's easy to imagine how it could benefit the fledgling Nova extension community.

The only wrinkle I can see from here is that I'd like to be able to import a module like this into Deno — but I know CDNs like Skypack handle that for you. The only thing it would need to avoid are any dependencies which rely on Node.

[apexskier]

I'm totally in favor of this.

I have https://github.com/apexskier/nova-extension-utils which has some some similar goals and could serve as a home if it made sense - its runtime is Nova, so it shouldn't depend on Node. (There are definitely other improvements that could be made if we ended up putting an LSP module in it). I haven't worked with Deno on anything real, so I'd need to pull down your extension and play with it a bit.

[sgwilym]

Sounds good! Here's an overview of the things I lifted:

• registerX + wrapCommand
• applyLspEdits
• applyWorkspaceEdits (modified to handle documentChanges)
• rangeToLspRange + lspRangeToRange

I also reused you method of setting up a listener for onWillSave.

[sgwilym]

Hello! I dawdled on this for a while because I wasn't really sure how to package it in a way that'd be useful for people developing extensions using Node and Deno (population: me) to assist them. But things moved on in the meantime, and I finally put together a POC here: https://github.com/sgwilym/nova_utils.

This package pulls together @types/nova-editor, the LSP code from this repo, and utilities from https://github.com/apexskier/nova-extension-utils into one place.

It's a little bit different to how those work now. Nova types and the nova global must be explicitly imported to use them:

import { nova, TextEditor, Transferrable } from "nova-extension-stuff";

These are just for Typescript's benefit — they're all shook out in the build.

I've got a branch of nova-deno that has been updated to use this and it works great, but I don't know how well tsc likes this approach.

Another small addition is that I updated applyWorkspaceEdit so that it supports both documentChanges and changes.

You can try it for yourself:

npm i nova-extension-stuff

or

import * as NovaUtils from "https://raw.githubusercontent.com/sgwilym/nova_utils/main/mod.ts";

Specifically I'd like to hear if this approach is even compatible with build tools in the Node ecosystem. I had some troubles with Esbuild.

The repo itself uses Deno as a runtime for development, and a NPM package is made out of it with the script in scripts/build_npm.ts. Any tests I eventually add will also be run against the NPM packaged version of the code.