Aral Balkan

Mastodon icon RSS feed icon

NodeKit extension for Codium

Screenshot of the NodeKit for Codium extension’s settings page in VSCodium.

NodeKit for Codium: a reluctant fork of Svelte Language Tools.

This past week, I cobbled together1 a very basic NodeKit extension for Codium.

Download

📦 nodekit-for-codium-0.5.0.vsix

💡 What’s NodeKit? Watch the NodeKit video introduction to find out.

Install

Either drag the downloaded package to the Extensions panel of Codium or, in your terminal, run the following command from the folder you downloaded the package to:

code --install-extension ./nodekit-for-codium-0.5.0.vsix

💡 If you have Svelte Language Tools installed, this extension will likely clash with it so please disable the other extension while playing with NodeKit.

Screenshot of index.page open in VSCodium. Code: <data>let count = 1; export default () => { return {count: count++} }</data> <script>export let data</script><h1>Hello, world!</h1><p>I’ve greeted you {data.count} time{data.count > 1 ? 's' : ''}.</p>

The NodeKit code in the example keeps a simple ephemeral server-side count and displays it in the browser when the page loads.

About

The NodeKit for Codium extension is a fork of Svelte Language Tools that:

Good, perfect and all that

I’m not happy with the current state of this extension but you know what they say about perfect being the enemy of the good.

Basically, without this extension, Codium gets in your way when you add the NodeKit <data> block to your code. With it, it doesn’t and you get proper Svelte language intelligence for your page as well as basic syntax highlighting for your <data> block.

Initially, I did try creating a separate tiny extension that uses request forwarding to forward requests for the <data> block and the rest of the document separately but that didn’t work. And, even if it had worked, being a client-side solution, it would have been Codium-specific.

A forking shame

So, like it or not, if I want other editors to support language intelligence for NodeKit in the future, I currently find myself in the unenviable position of having to fork the Svelte language server.

It is sad that there isn’t a cleaner way to basically say, at the language server level, “hey, see this … region? Treat it as JavaScript.”

I mean this is essentially what the Svelte language server itself does by forwarding different regions of Svelte files to different language services and using source maps to translate the results back but it is not trivial to implement (2).

I’ll likely eventually end up modifying the Svelte language server far more extensively to add proper support for <data> and other NodeScript blocks (like <post>, <socket>, etc.)

Right now, however, given the extension is currently good enough – if not anywhere near perfect – I’m going to get back to developing the core of NodeKit as I build Domain using it.

If you’re playing with NodeKit at this very early stage, I hope the existence of this extension makes your life a little easier. I’m going to keep thinking about tooling around NodeKit to try and balance not recreating the wheel with having a first-rate developer experience.

  1. Or, “Bled for a week to try and get something better together within the limitations of the Language Server Protocol while wading through The Incredible Machine that is the Svelte Language Tools monorepo but finally settled on something that works for now even if it’s not perfect.” ↩︎

  2. At one point it even transpiles the Svelte source to TSX to make use of the TypeScript language service, which is a pragmatic move but it does end up creating the aforementioned Incredible Machine to decipher, especially when you’re first diving through the code. There is, however, a helpful overview of the language-tools and how things work together document that will make your life easier. ↩︎