Though this post is a bit minor content, please refer this when you need to migrate from Jest to Node.js built-in test runner (node:test).

Use Node.js Type Stripping or Deno when you start a new project or your current project doesn't have large codebase.

I've decided to use tsx (not Type Stripping) for transpiler because we need to migrate regular TypeScript source code to ESModule first and Type Stripping doesn't support *.tsx.

Environment

• Node.js v22.x
  • "type": "commonjs"
• tsx@4
• typescript@5

tsconfig.json example (Some options are not important.)

{
  "compilerOptions": {
    "lib": ["ES2023"],
    "baseUrl": ".",
    "allowSyntheticDefaultImports": true,
    "erasableSyntaxOnly": true,
    "strict": true,
    "esModuleInterop": true,
    "module": "Node18",
    "moduleResolution": "Node16",
    "target": "ES2022"
  },
  "include": ["src/**/*"]
}

Steps

1. Use @jest/globals instead of @types/jest if you use global Jest APIs (prefer-importing-jest-globals of eslint-plugin-jest would be helpful.)
2. Use node:assert instead of Jest expect API
3. Use sinon or other mocking libraries instead of Jest mocking APIs (e.g. jest.mock(), jest.spyOn())
4. Migrate {it,test}.each() w/ regular JS loop

After all of them are applied, you would run test via node --test instead of jest.

expect -> node:assert

// before

import { describe, expect, it } from "@jest/globals";

describe("foo()", () => {
  it("returns 'foo'", () => {
    expect(foo()).toEqual("foo");
  });
});

// after

import { describe, it } from "@jest/globals";
import assert from "node:assert/strict";

describe("foo()", () => {
  it("returns 'foo'", () => {
    assert.equal(foo(), "foo");
  });
});

jest.mock() -> sinon

If your stub, spy, or mock target is not an object, change source code first because tsx (esbuild) can't handle it. see

Before

// src/bar.ts

export function bar(): string {
  return "bar";
}

// src/foo.ts

import { bar } from "./bar";

export function fooBar(): string {
  return `foo${bar()}`;
}

// src/foo.test.ts

import { fooBar } from "./foo";

import * as barMod from "./bar";

import { afterEach, beforeEach, describe, it } from "@jest/globals";
import assert from "node:assert/strict";
import sinon from "sinon";

describe("fooBar()", () => {
  let barStub: sinon.SinonStub;

  beforeEach(() => {
    barStub = sinon.stub(barMod, "bar");
  });

  afterEach(() => {
    barStub.restore();
  });

  it("returns 'fooXXX'", () => {
    // This fails
    barStub.returns("XXX");

    assert.equal(fooBar(), "fooXXX");
  });
});

After

// src/bar.ts

export const barMod = {
  bar(): string {
    return "bar";
  },
};

// src/foo.ts

import { barMod } from "./bar";

export function fooBar(): string {
  return `foo${barMod.bar()}`;
}

// src/foo.test.ts

import { foo } from "./foo";

// This works
import { barMod } from "./bar";

// ...

it.each -> regular JS loop

// before
it.each([
  { input: {}, expected: { page: 1, limit: 20 } },
  { input: { name: "foo" }, expected: { name: "foo", page: 1, limit: 20 } },
  {
    input: { name: "", page: "2", limit: "50" },
    expected: { page: 2, limit: 50 },
  },
])("returns $expected w/ $input", ({ input, expected }) => {
  assert.deepEqual(validate(input), expected);
});

// after
[
  { input: {}, expected: { page: 1, limit: 20 } },
  { input: { name: "foo" }, expected: { name: "foo", page: 1, limit: 20 } },
  {
    input: { name: "", page: "2", limit: "50" },
    expected: { page: 2, limit: 50 },
  },
].forEach(({ input, expected }) => {
  it(`returns ${JSON.stringify(expected)} w/ ${JSON.stringify(input)}`, () => {
    assert.deepEqual(validate(input), expected);
  });
});

Command

The test command would be like this:

$ node --import=tsx --test '**/*.test.*'

Node.js test runner mocks

After the migration, you can use Node.js test runner's mocking APIs.

But you need a bit hard work for Module Mocking. (and you need --experimental-test-module-mocks flag)

The former example would be like the following:

src/foo/foo.test.ts

// no mocks are used in this file.

import { foo } from "./foo";

import assert from "node:assert/strict";
import { describe, it } from "node:test";

describe("foo()", () => {
  it("returns 'foo'", () => {
    assert.equal(foo(), "foo");
  });
});

src/foo/foo-bar.test.ts

// mocks are used in this file.

import assert from "node:assert/strict";
import { beforeEach, describe, it, mock } from "node:test";

describe("fooBar()", () => {
  let barMock = mock.fn<() => string>();
  let fooBar: () => string;

  beforeEach(async () => {
    // This can stub function
    mock.module("./bar", {
      namedExports: { bar: barMock },
    });

    // Load the target file after mocking
    ({ fooBar } = await import("./foo.js"));
  });

  it("returns 'fooXXX'", () => {
    barMock.mock.mockImplementation(() => "XXX");

    assert.equal(fooBar(), "fooXXX");
  });
});

I hope the Module Mocking API will be better in the future.

A main project I currently tackle on adopts DDD architecture. But nobody in the project understands it correctly:

• business logic spreads across everywhere
• empty Entities just like DTO
• Service classes with no business logic
• etc.

Due to this situation, I'm now trying to improve application structure. Of cource, it's the best to use a framework that has strict rules about app/dir structure. The project is a legacy, express.js based one, tho.

One important thing is reducing roles (layers). There're many layers and objects in the current architecture. Everyone confuses what/where things should be put. And I realized it makes sense that Ruby on Rails adopts MVC patterns.

Structure

One of the ideas will be based on NestJS approach (see the tutorial).

Web applications are normally the following 4 steps:

1. receives a request
2. validates it
3. applies business logic
4. returns a response.

To acheive this, app structure can be like this:

app/
  posts/
    posts.router.ts
    posts.handlers.ts
    posts.validator.ts
    posts.service.ts

• posts.router.ts handles /posts/* requests.
• posts.service.ts hanldes a part of 3.

// posts.router.ts
export const postsRouter = defineRouter("/posts", (r) => {
  // GET /posts
  r.get("/", indexHandler);

  // GET /posts/:id
  r.get("/:id", showHandler);

  // GET /posts/new
  r.get("/new", newHandler);

  // POST /posts
  r.post("/", createHandler);

  // GET /posts/:id/edit
  r.get("/:id/edit", editHandler);

  // PATCH /posts/:id
  r.patch("/:id", updateHandler);

  // DELETE /posts/:id
  r.delete("/:id", destroyHandler);
});

// posts.handlers.ts
export const indexHandler = defineHandler(async (req, res) => {
  const options = validateSearchOptions(req.query);
  const { posts, total, cursor } = await service.fetchList(options);
  res.json({ data: { posts }, total, cursor });
});

export const createHandler = defineHandler(async (req, res) => {
  const data = validatePost(req.body);
  const post = await service.create(data);
  res.status(201).json({ data: { post } });
});

You can also arrange the structure like this:

app/
  posts/
    posts.router.ts
    posts.service.ts
    _index/
      index.handler.ts
      index.validator.ts
    _create/
      create.handler.ts
      create.validator.ts

it can be like the following for more realistic monolith apps:

apps/
  admin/   # admin.example.com/
    posts/
      posts.router.ts
      # ...
  web/     # www.example.com/
    posts/
      posts.router.ts
      # ...

Other common layers like persistent layer, middlewares, logger, etc. is like this:

app/
  # ...
lib/
  entities/
    post.ts
    user.ts
  middlewares/
    not-found.middleware.ts
    server-error.middleware.ts
  repositories/
    post.repository.ts
    user.repository.ts
  logger.ts
  define-handler.ts
  define-router.ts

ActiveRecord pattern vs Repository pattern

I'd thought Repository pattern would be better than ActiveRecord pattern for several years. But I have to consider using AR if project members aren't skilled enough.

Final Comment

I'm just trying this now and don't know what I feel in future.

It's not hard at all to introduce ESLint to a new project, but so hard for a legacy project.

Although there are several ways to do this, I'll leave a better way for myself.

Steps

1. Upgrade eslint version as far as possible
2. List up "rules" w/ "error"
3. Add TODO list in "overrides" per directory w/ "warn"
4. Run with --max-warnings=0 option to newly added files on CI

1. Upgrade eslint version as far as possible

If eslint libs are installed in your project, you should upgrade them as far as possible.

The rules may behave differently and have better options after the upgrade.

2. List up "rules" w/ "error"

After upgrading or installing the eslint libs, you would set up .eslintrc.js.

By the way, I'm explaining this with the old eslint config file in this post. But the technique itself is also applicable to new config file.

// .eslintrc.js

module.exports = {
  // ...

  rules: {
    "@typescript-eslint/no-implicit-any": ["error"],
  },
  // ...
};

In this phase, your project may not have passed eslint on CI, but it's OK for now.

3. Add TODO list in "overrides" per directory w/ "warn"

To mitigate the violations, you can list up the directory list with "warn".

Suppose your project is built using the MVC style.

// .eslintrc.js

module.exports = {
  // ...

  overrides: [
    // TODO: remove listed dir after fixing the violations.
    {
      files: [
        "src/controllers/admin/**/*.ts",
        "src/controllers/web/**/*.ts",
        "src/models/**/*.ts",
        "src/lib/**/*.ts",
      ],
      rules: {
        "@typescript-eslint/no-implicit-any": ["warn"],
      },
    },
  ],
};

For example,

1. fix no-implicit-any violations under the src/controlles/admin/*
2. remove the line "src/controllers/admin/**/*.ts"
3. violations can be detected under the directory

4. Run with --max-warnings=0 option to newly added files on CI

This is an optional, but very effective.

You can apply stricter rules to new files. This can be done with the following command:

# `remotes/origin/main` can be replaced with your base branch.
$ eslint \
    --max-warnings=0 \
    $(git diff --name-only --diff-filter=A remotes/origin/main HEAD)

ref: https://stackoverflow.com/a/15535048

If the new files are violated against any "warn" rules, they are detected as "error".

You can avoid violated files are added in your project.

I had been looking for an alternative static site generator built in Deno and deno_blog was a candidate. But it currently doesn't support pagination (p-r exists tho).

lume is almost the same as hugo, at least for me, it's enough. First I thought I need to design entire site by myself, but I found theme-simple-blog can be used as a plugin (like hugo theme).

Then I tried to migrate my blog to lume and I could. It just took less than an hour.

The steps was like following:

1. Run init command (deno run -A https://deno.land/x/lume/init.ts) under the root of the blog repo.
2. Remove extra content directory for the posts
3. Remove unnecessary hugo files
4. Add _data.yml
5. Add my own about.md
6. Update .gitignore
7. Add them-simple-blog plugin

I've also migrated the hosting from Netlfiy to Deno Deploy.

See the setup detail here.

I am now satified with it :)

next-fetch is useful when you use both SWR and Next.js API Routes.

But currently the documentation is poor. I am a bit struggled with how to use hookResponse option in query or mutation.

Usage

⚠️ This is just for @next-fetch/swr@0.0.2 and could be changed in future versions.

For API routes, see the doc.

// pages/form.tsx

export default function MyFormPage() {
  return (
    <form action="/api/simple?__handler=useMutation" method="POST">
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

Conclusion

runtime: "experimental-edge" behaves differently from runtime: "nodejs".

It returns different HTTP response headers and I will explain the detail in this post (although this might be wrong partially.)

My Concern

Next.js v12.2 introduces Edge Runtime.

I'd just understood it couldn't use Node.js standard APIs and was lightweight.

But I was not sure how this worked and how differed from runtime: "nodejs" and wondered whether this affected when choosing self-hosted.

The official document says like this:

Edge API Routes can stream responses from the server and run after cached files (e.g. HTML, CSS, JavaScript) have been accessed.

...OK, I will test the new API routes!

Test Code

Set experimental.runtime: "nodejs" in next.config.js

pages/api/test.ts uses runtime: "nodejs":

import { NextApiHandler } from "next";

const handler: NextApiHandler = async (_req, res) => {
  res.status(200).json({ name: "Jim Halpert" });
};

export default handler;

pages/api/test-edge.ts uses runtime: "experimental-edge":

import { NextApiHandler } from "next";

export const config = {
  runtime: "experimental-edge",
};

const handler: NextApiHandler = async (_req, res) => {
  // see: https://nextjs.org/docs/api-routes/edge-api-routes#json-response
  return new Response(
    JSON.stringify({
      name: "Jim Halpert",
    }),
    {
      status: 200,
      headers: {
        "Content-Type": "application/json; charset=utf-8",
      },
    },
  );
};

export default handler;

Both of them returns the same response body.

Result

I picked up only response headers part.

curl -v http://localhost:xxx/api/test

< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< ETag: "16-DlZOPLD8Q/zEnYFRYsdmnqlUPWI"
< Content-Length: 22
< Vary: Accept-Encoding
< Date: Thu, 30 Jun 2022 11:42:50 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5

curl -v http://localhost:xxx/api/test-edge

< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
< Date: Thu, 30 Jun 2022 11:43:39 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< Transfer-Encoding: chunked

experimental-edge runtime:

• lacks ETag, Content-Length, and Vary headers
• adds Tranfer-Encoding: chunked header

Transfer-Encoding: chunked sends HTTP repsonse as chunk (or stream) according to MDN doc.

• With this header, Content-Length is omitted from the doc.
• It's understandable Vary: Accepct-Encoding is omitted for this endpoint because Transfer-Encoding is specified (chunks are always sent).
• The reason ETag is dropped, I guess, might be that the endpoint could not end in a single request.

Again, my understanding for HTTP is not enough and this post might be wrong. Please check correct sources by yourself.

References

• Blog - Next.js 12.2 | Next.js
• Edge Runtime | Next.js
• API Routes: Edge API Routes (Beta) | Next.js
• ETag - HTTP | MDN
• Vary - HTTP | MDN
• Transfer-Encoding - HTTP | MDN

I had ever struggled and gave up running chromedriver in normal WSL(WSL2) environment before, so I thought this was a good opportunity.

The following step is limited for WSL2 + Pengwin distro that I've been using.

Environment

• OS: Windows 11, 21H2, 22000.708
• GPU: GeForce RTX 2080

Steps

ref: GUI app support has arrived for the Windows Subsystem for Linux on the latest Windows Insiders Preview build 21362+ and Pengwin supports it out of the box — Whitewater Foundry

1. Install NVIDIA GPU driver for WSL
2. Install required packages in WSL

pengwin-setup update

# Open setup dialog
# and select [GUI], then install necessary packages.
pengwin-setup

After package installation, restart WSL (or restart Windows).

Install Google Chrome

ref: https://github.com/microsoft/wslg#install-and-run-gui-apps

cd /tmp
sudo wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb
sudo apt install --fix-broken -y
sudo dpkg -i google-chrome-stable_current_amd64.deb

# Start Google Chrome app in Linux GUI for test
google-chrome

Install chromedriver

ref: https://tecadmin.net/setup-selenium-with-chromedriver-on-debian/

# 1. check your google chrome version on WSLg
# 2. Download the same version of chromedriver with google-chrome
#    http://chromedriver.storage.googleapis.com/index.html
#    The version was 102.0.5005.61 this time.

cd /tmp
wget http://chromedriver.storage.googleapis.com/102.0.5005.61/chromedriver_linux64.zip
unzip chromedriver_linux64.zip
sudo mv chromedriver /usr/bin/chromedriver
sudo chown root:root /usr/bin/chromedriver
sudo chmod +x /usr/bin/chromedriver

Run the following script when you want to test.

ref: https://www.npmjs.com/package/selenium-webdriver

/**
 * $ npm init -y
 * $ npm install selenium-webdriver
 * $ vim main.js
 */

// main.js
const { Builder, Browser, By, Key, until } = require("selenium-webdriver");

(async function main() {
  const driver = await new Builder().forBrowser(Browser.CHROME).build();
  try {
    await driver.get("http://www.google.com/ncr");
    await driver.findElement(By.name("q")).sendKeys("webdriver", Key.RETURN);
    await driver.wait(until.titleIs("webdriver - Google Search"), 1000);
    // Replace the string with 'webdriver - Google 検索' when your language setting is Japanese.
  } finally {
    await driver.quit();
  }
})();

// node main.js

<form action="#">
  <fieldset disabled>
    <!-- like this -->
    <legend>Sign in</legend>

    <label for="email">Email</label>
    <input id="email" name="email" type="email">

    <label for="password">Password</label>
    <input id="password" name="password" type="password">

    <input type="submit">
    <!-- button is also disabled
      <button>Submit</button>
    -->
  </fieldset>
</form>

see:

interface Post {
  id: number;
  title: string;
}

const posts: Post[] = [
  { id: 1, title: "a" },
  { id: 2, title: "b" },
  { id: 3, title: "c" },
  { id: 4, title: "d" },
  { id: 5, title: "e" },
  { id: 6, title: "f" },
  { id: 7, title: "g" },
  { id: 8, title: "h" },
  { id: 9, title: "i" },
  { id: 10, title: "j" },
];

// Dummy ORM API
const db = {
  post: {
    findMany({ take, skip }: { take: number; skip: number }): Promise<Post[]> {
      return Promise.resolve(posts.slice(skip, skip + take));
    },
  },
};

function postStream(take: number): ReadableStream<Post> {
  let skip = 0;

  return new ReadableStream<Post>(
    {
      async pull(controller) {
        const posts = await db.post.findMany({
          skip,
          take,
        });
        for (const post of posts) {
          controller.enqueue(post);
        }

        if (posts.length < take) {
          controller.close();
          return;
        }

        skip = skip + take;
      },
    },
    { highWaterMark: take },
  );
}

function toCSV(take: number): TransformStream<Post, string> {
  return new TransformStream<Post, string>(
    {
      start(controller) {
        controller.enqueue(`id,title`);
      },
      transform(chunk, controller) {
        controller.enqueue(`${chunk.id},${chunk.title}`);
      },
      flush(controller) {
        controller.terminate();
      },
    },
    {
      highWaterMark: take,
    },
  );
}

const take = 3;
const stream = postStream(take).pipeThrough(toCSV(take));
for await (const chunk of stream) {
  console.log(chunk);
}

// tmp/
//   test.ts
//   test.json

import { readableStreamFromReader } from "https://deno.land/std@0.140.0/streams/mod.ts";

const file = await Deno.open("./tmp/test.json", { read: true });

// Uint8Array
const byteStream = readableStreamFromReader(file);

// Uint8Array -> String
const decodedStream = byteStream.pipeThrough(new TextDecoderStream());

for await (const chunk of decodedStream) {
  console.log({ chunk: JSON.parse(chunk) });
}

// $ deno run --allow-read ./tmp/test.ts