Max Netterberg | Software Engineer, Tinkerer, Hobby gastronomer and Maniac Programmer. Javascript, Typescript, Node.js, Golang, Rust

# Hello Neovim!

My first project as a junior developer I started out coding in the Atom editor. At the time I was not aware of the helpful tooling software engineers relied on. Therefore I was rawdogging it without any LSP, automatic formatting, linting or syntax highlighting. Life was hard 🐶.

Making the switch to Neovim can be hard and daunting for many vscode users. This post describes my journey switching to Neovim from Visual Studio Code

Migrating to Neovim from VS Code

migrating-from-vscode-to-nvim

# Why you might not need Jest anymore

A good argument for using some new technology is always

> it's native

or

> it's included in the standard library

Using code which is officially supported by the language rarely has downsides. It's pretty much guaranteed to not become outdated, it's updated when you update your language version and code from the std-library is never going to become a stale project because of open source drama (looking at you 🦀-foundation).

## import test from 'node:test';

[The node test runner](https://nodejs.org/api/test.html) is now stable since node v20.0.0. Usually I just reach for jest to run my tests but seeing how jest has had such a big problem with es-modules I reached out to the native node test runner to give it a shot. Fortunately the node:test api has been heavily inspired by jest's api making a transition quite easy. This also makes sense since jest has been the industry standard for testing in node for a while now.

## Creating a test

Creating a test in jest and node looks eerily similar:


```typescript Jest
describe("maths", () => {
  it("should sum", () => {
    expect(1 + 2).toEqual(3);
  });
});
```

---

```typescript Node
import { describe, it } from "node:test";
import assert from "node:assert";

describe("maths", () => {
  it("should sum", () => {
    assert.strictEqual(1 + 2, 3);
  });
});
```

The only major difference is the node test runner requires you to import the functions called. Which I prefer since it removes the "magic" part of creating the tests while still keeping them declarative.

## Testing async functions

Async functions are first class citizens in the node:test module:

```typescript Jest
describe("maths", () => {
  it("should sum", async () => {
    expect(1 + 2).toEqual(3);
  });
});
```

---

```typescript Node
import { describe, it } from "node:test";
import assert from "node:assert";

describe("maths", () => {
  it("should sum", async () => {
    assert.strictEqual(1 + 2, 3);
  });
});
```

The api works the same, any async function which returns a rejected promise in the `it` function is a failed test. That means this is also a failed test:

```typescript Node
import { describe, it } from "node:test";
import assert from "node:assert";

describe("maths", () => {
  it("should sum", () => {
    return Promise.reject();
  });
});
```

## Type assertions

The node assert package also has a neat feature in that it returns the `asserts value` return type which means you will get first class typescript support in your tests.

In a typical jest test this would not narrow the type to a string even though we clearly have asserted that the type is supposed to be a string


```typescript Jest
describe("test", () => {
  let thing: string | undefined;
  expect(typeof thing === "string");
  // Typescript still thinks this type is string | undefined
  thing;
});
```

The asserts package in node will correctly infer the narrowed type

```typescript Node
import { describe } from "node:test";
import assert from "node:assert";

describe("test", () => {
  let thing: string | undefined;
  assert(thing);
  // Typescript correctly narrows this variables type to string
  thing;
});
```

## Hooks

The node api also has support for the regular lifecycle hooks jest also exposes such as `beforeAll`, `beforeEach`, `afterAll` and `afterEach` allowing you to setup and destroy resources and mocks needed for tests:


```typescript Jest
beforeEach(() => {
  initializeDatabase();
});

afterEach(() => {
  clearDatabase();
});

beforeAll(() => initializeDatabase());

afterAll(() => clearDatabase());

describe("test", () => {
  it("should sum", async () => {
    expect(1 + 2).toEqual(3);
  });
});
```

Again, node requires you to import these lifecycle hooks from the `node:test` module

```typescript Node
import { describe, it, before, after, beforeEach, afterEach } from "node:test";
import assert from "node:assert";

beforeEach(() => {
  initializeDatabase();
});

afterEach(() => {
  clearDatabase();
});

before(() => initializeDatabase());

after(() => clearDatabase());

describe("test", () => {
  it("should sum", async () => {
    assert.strictEqual(1 + 2, 3);
  });
});
```

Node’s built-in test runner covers the essentials, making Jest unnecessary in most cases. This article explores when to choose Node's test runner over libraries like Jest.

Why you might not need Jest anymore

node-test-runner

# Typescript Executor

A couple of months ago, I gave a presentation on TypeScript decorators. I
called it ["Demystifying Decorators"](https://redsuperbat.github.io/demystifying-decorators/), and it
focused on creating a dependency injection library in TypeScript using
decorators.

I wanted to present code in an intuitive way, especially since the audience was
primarily developers. I found a really awesome framework for creating
presentations from HTML called [Reveal](https://reveal.com).

Reveal came with a great toolkit that helped me display code and smoothly transition between slides.

Simple code like this made for a really nice slide:

```html
<section>
  <h2>Demystifying Decorators</h2>
  <p>How do <code>@Decorators()</code> really work?</p>
  <p>And what can they be used for? 🤷</p>
</section>
```

![Decorators](decorators.png)

Even though Reveal has great support for displaying code, it doesn't support
executing code live during presentations. This was something I really wanted,
as running code live can significantly enhance understanding—especially in a
very *techy* presentation like mine.

Reveal has a solid plugin system, so I started looking for a plugin that could
execute code. I found [this repo](https://github.com/stanleynguyen/reveal-run-in-terminal), which is a
plugin that exposes the terminal to run arbitrary console commands such as
`node` or `python`, allowing you to execute the code displayed in your slides.

However, it had some limitations. You have to run a command in the presentation
that points to a file containing the same code shown on the slide. Also, if I
wanted to run code that depended on external packages, I'd have to install
those packages on my machine ahead of time.

What I really wanted was the ability to press a button, run *any* code shown on
the screen, and display the standard output right in the
presentation—regardless of dependencies or whether I was using TypeScript or
JavaScript.

So, I concluded that I needed two things:

A **server** that could:
   - Accept code,
   - **Transpile** it if it's TypeScript,
   - Fetch and install any external dependencies from `npm`,
   - Execute the code, and
   - Return whatever logs were printed to standard output.

A **Reveal plugin** that could:
   - Send the content of code blocks to that server, and
   - Display the returned output in the presentation.


## Making the executor

To make an API which could execute typescript code and return the results we can use any http framework. I opted to use [`fastify`](https://fastify.dev/) since it's supposed to be blazingly fast 🔥.

```typescript index.ts
import cors from "@fastify/cors";
import init from "fastify";
const fastify = init({ logger: true, requestTimeout: 60_000 });

fastify.post("/", async (req, _) => {
  const tsCode = String(req.body);
});

const start = async () => {
  try {
    await fastify.register(cors);
    await fastify.listen({ port: 3000, host: "0.0.0.0" });
  } catch (err) {
    fastify.log.error(err);
    process.exit(1);
  }
};
start();
```

Since we want to be able to send Typescript code we have to transpile the code, this can be done with the `typescript` package:

```typescript index.ts
import { transpile, ModuleKind, ScriptTarget } from "typescript";

const js = transpile(tsCode, {
  experimentalDecorators: true,
  emitDecoratorMetadata: true,
  module: ModuleKind.ES2015,
  target: ScriptTarget.ES2015,
});
```

The executor should also be able to download arbitrary dependencies declared in the code. There is a great library which is made by Google called [`zx`](https://GitHub.com/google/zx) which can help us with that:

```typescript index.ts
import { exec } from "child_process";
import { randomUUID } from "crypto";
import { rm, writeFile } from "fs/promises";

function cmd(command: string) {
  let p = exec(command);
  return new Promise<string>((res) => {
    let stdout = "";
    const append = (data: any) => {
      data = data.toString() as string;
      if (data.includes(" npm i ")) return;
      stdout += data;
    };
    p.stdout?.on("data", append);
    p.stderr?.on("data", append);
    p.on("exit", () => {
      res(stdout.trim());
    });
  });
}

const filename = randomUUID();
await writeFile(filename, js);
try {
  const output = await cmd(`zx --install --quiet ./${filename}`);
  console.log(output);
  return output;
} finally {
  await rm(filename);
}
```

`zx` is intended to be used for scripting generally, but it really fit this use
case well since it can install dependencies with the `--install` flag. By
writing the javascript to a temporary file and pointing `zx` to that file we
are avoiding having to interpolate Javascript code into the command line.

Great! Now we can package this app up with Docker and run it in a container for easy management.

```Dockerfile
FROM node as builder

WORKDIR /app

COPY package*.json .

RUN npm install

COPY . .

RUN npm run build

FROM node as runner

WORKDIR /app

RUN npm install -g zx

COPY --from=builder /app/node_modules node_modules

COPY --from=builder /app/index.js index.js

CMD [ "node", "index.js" ]
```

## Making the plugin

The plugin needs to attach to all of the code elements in reveal.js and inject
some JavaScript which will send a http request with the code content to the
executor and then display the response.

```javascript reveal-code-exec.js
window.RevealCodeExec = ({ execUrl }) => ({
  id: "code-exec",
  init: () => {
    const codeblocks = document.querySelectorAll("pre.code-wrapper[runnable]");
    for (const code of codeblocks) {
      const runTheCode = "Run the code!";
      const div = document.createElement("div");
      code.contentEditable = "true";
      code.style.position = "relative";
      div.style.cursor = "pointer";
      div.style.width = "100%";
      div.style.zIndex = "10";
      div.style.top = "100%";
      div.style.bottom = "0";
      div.style.background = "white";
      div.style.position = "absolute";
      div.innerText = runTheCode;
      div.style.height = "fit-content";
      div.onclick = async () => {
        if (div.innerText !== runTheCode) {
          return (div.innerText = runTheCode);
        }
        div.innerText = "Loading...";
        const body = (
          code.querySelector("code.visible.current-fragment") ||
          code.querySelector("code")
        ).textContent;
        const res = await fetch(execUrl, {
          method: "POST",
          body,
        });
        if (!res.ok) {
          div.innerText = runTheCode;
          return;
        }
        const text = await res.text();
        div.innerText = text || runTheCode;
      };
      code.appendChild(div);
    }
  },
});
```

We attach a function to the global window object and register it as a plugin in `index.html`

```html
<script src="plugin/code-exec/plugin.js"></script>
<script>
  Reveal.initialize({
    hash: true,
    plugins: [
      RevealMarkdown,
      RevealHighlight,
      RevealNotes,
      RevealCodeExec({ execUrl: "http://localhost:8080" }),
    ],
  });
</script>
```

Now we should be able to run the code in the presentation by pressing the `Run the code!` button

![console-log.png](console-log.png)

Pressing the button yields this result:

![console-log-result.png](console-log-result.png)

## Conclusion

If you made it this far, thanks for sticking along and hope your learned something new.

Another cool thing about using reveal is that you can embed the presentation in an iframe. Below is an example of that 👇

<iframe style="width: 100%; height: 400px;" src="https://redsuperbat.github.io/demystifying-decorators/#/1">
</iframe>

Happy coding! 🌈

Making interactive presentations are fun. I created one with reveal.js and adding live code execution with a typescript transpiler and executor

Making a typescript executor

typescript-executor

# Rustproof

[Rustproof github repo](https://github.com/redsuperbat/rustproof)

Spelling is hard, especially when you're writing text all day long and the
value you provide isn't measured by the conciseness of your code but rather its
correctness.

For a developer, spelling is just the icing on the cake. Regardless it's nice
not to have to read spelling mistakes all day.

Since my code always conveys proper intent 💁 and I was struggling with the
spelling part, I decided to use a spellchecker for my code.

I started by using cspell, a fairly popular spellchecker that uses LSP to
communicate spelling errors to my editor. It worked fine for most files, but it
sometimes became unhinged when files were over 1000 lines, with the CPU hitting
100% and memory usage skyrocketing. At some point, I had to add a file size
check to my LSP config in Neovim to explicitly prevent cspell from running on
large files. 😮‍💨

Adding additional languages was also a pain. I'm Swedish and maintain some
websites with Swedish copy, which was unknowingly littered with spelling
errors. I tried adding the Swedish cspell dictionary, but after an hour of
searching and trial and error, I gave up and opted to disable cspell LSP in
projects with Swedish copy.

After some time, I stumbled upon [harper-ls](https://writewithharper.com/), a
fantastic project I thought would solve all my problems. However, it fell short
since it could only spellcheck comments and markdown, essentially addressing a
different need than what cspell was doing.

Therefore, I decided to create my own code spellchecker, and rustproof was
born.

Rustproof has a simple architecture very common to how cspell works but
leverages [hunspell](https://hunspell.github.io) in order to spellcheck words.
This allows Rustproof to load dictionaries from any language supported by
hunspell. Below you can see a demonstration of the LSP in action:

<img src="https://github.com/user-attachments/assets/ad313dcb-fac7-4df7-afbb-47f95ecf2e2f" />

Spellchecking code is nice. After not having much luck with other spellcheckers I wrote my own.

Rustproof - Extensible code spellchecker written in rust

rustproof

# Neon programming language

A compact, expression-based language built in Rust 🦀

This language offers a concise yet powerful feature set:

- Expression-based syntax
- Basic arithmetic operations (addition, subtraction, modulus)
- Control flow structures (if, else, else if)
- Support for recursion

Feel free to try it out in the playground 👇

<iframe style="width: 100%; height: 40rem;" src="https://redsuperbat.github.io/neon">
</iframe>

This playground is an embedded iframe that links to [the full version](https://redsuperbat.github.io/neon). For the best experience, feel free to visit the full site directly.

To sharpen my Rust skills, I developed a programming language using Rust

Max Netterberg

Useful links ✨

Projects

Rustproof

Neon programming language

Posts

Why you might not need Jest anymore

Typescript Executor