Though this post is a bit minor content, please refer this when you need to\nmigrate from Jest to Node.js built-in test runner\n(node:test).
Use Node.js Type Stripping or Deno when you start a new project or your current\nproject doesn't have large codebase.
\nI've decided to use tsx (not Type\nStripping) for transpiler because we need to migrate regular TypeScript\nsource code to ESModule first and Type Stripping doesn't support *.tsx.
"type": "commonjs"tsconfig.json example (Some options are not important.)
{\n "compilerOptions": {\n "lib": ["ES2023"],\n "baseUrl": ".",\n "allowSyntheticDefaultImports": true,\n "erasableSyntaxOnly": true,\n "strict": true,\n "esModuleInterop": true,\n "module": "Node18",\n "moduleResolution": "Node16",\n "target": "ES2022"\n },\n "include": ["src/**/*"]\n}\n@jest/globals instead of\n@types/jest if you use global Jest APIs\n(prefer-importing-jest-globals\nof eslint-plugin-jest\nwould be helpful.)node:assert\ninstead of Jest expect APIjest.mock(), jest.spyOn()){it,test}.each() w/ regular JS loopAfter all of them are applied, you would run test via node --test instead of\njest.
expect -> node:assert// before\n\nimport { describe, expect, it } from "@jest/globals";\n\ndescribe("foo()", () => {\n it("returns 'foo'", () => {\n expect(foo()).toEqual("foo");\n });\n});\n\n// after\n\nimport { describe, it } from "@jest/globals";\nimport assert from "node:assert/strict";\n\ndescribe("foo()", () => {\n it("returns 'foo'", () => {\n assert.equal(foo(), "foo");\n });\n});\njest.mock() -> sinonIf your stub, spy, or mock target is not an object, change source code first\nbecause tsx (esbuild) can't handle it.\nsee
// src/bar.ts\n\nexport function bar(): string {\n return "bar";\n}\n\n// src/foo.ts\n\nimport { bar } from "./bar";\n\nexport function fooBar(): string {\n return `foo${bar()}`;\n}\n\n// src/foo.test.ts\n\nimport { fooBar } from "./foo";\n\nimport * as barMod from "./bar";\n\nimport { afterEach, beforeEach, describe, it } from "@jest/globals";\nimport assert from "node:assert/strict";\nimport sinon from "sinon";\n\ndescribe("fooBar()", () => {\n let barStub: sinon.SinonStub;\n\n beforeEach(() => {\n barStub = sinon.stub(barMod, "bar");\n });\n\n afterEach(() => {\n barStub.restore();\n });\n\n it("returns 'fooXXX'", () => {\n // This fails\n barStub.returns("XXX");\n\n assert.equal(fooBar(), "fooXXX");\n });\n});\n// src/bar.ts\n\nexport const barMod = {\n bar(): string {\n return "bar";\n },\n};\n\n// src/foo.ts\n\nimport { barMod } from "./bar";\n\nexport function fooBar(): string {\n return `foo${barMod.bar()}`;\n}\n\n// src/foo.test.ts\n\nimport { foo } from "./foo";\n\n// This works\nimport { barMod } from "./bar";\n\n// ...\nit.each -> regular JS loop// before\nit.each([\n { input: {}, expected: { page: 1, limit: 20 } },\n { input: { name: "foo" }, expected: { name: "foo", page: 1, limit: 20 } },\n {\n input: { name: "", page: "2", limit: "50" },\n expected: { page: 2, limit: 50 },\n },\n])("returns $expected w/ $input", ({ input, expected }) => {\n assert.deepEqual(validate(input), expected);\n});\n\n// after\n[\n { input: {}, expected: { page: 1, limit: 20 } },\n { input: { name: "foo" }, expected: { name: "foo", page: 1, limit: 20 } },\n {\n input: { name: "", page: "2", limit: "50" },\n expected: { page: 2, limit: 50 },\n },\n].forEach(({ input, expected }) => {\n it(`returns ${JSON.stringify(expected)} w/ ${JSON.stringify(input)}`, () => {\n assert.deepEqual(validate(input), expected);\n });\n});\nThe test command would be like this:
\n$ node --import=tsx --test '**/*.test.*'\nAfter the migration, you can use Node.js test runner's mocking APIs.
\nBut you need a bit hard work for Module Mocking. (and you need\n--experimental-test-module-mocks flag)
The former example would be like the following:
\nsrc/foo/foo.test.ts
// no mocks are used in this file.\n\nimport { foo } from "./foo";\n\nimport assert from "node:assert/strict";\nimport { describe, it } from "node:test";\n\ndescribe("foo()", () => {\n it("returns 'foo'", () => {\n assert.equal(foo(), "foo");\n });\n});\nsrc/foo/foo-bar.test.ts
// mocks are used in this file.\n\nimport assert from "node:assert/strict";\nimport { beforeEach, describe, it, mock } from "node:test";\n\ndescribe("fooBar()", () => {\n let barMock = mock.fn<() => string>();\n let fooBar: () => string;\n\n beforeEach(async () => {\n // This can stub function\n mock.module("./bar", {\n namedExports: { bar: barMock },\n });\n\n // Load the target file after mocking\n ({ fooBar } = await import("./foo.js"));\n });\n\n it("returns 'fooXXX'", () => {\n barMock.mock.mockImplementation(() => "XXX");\n\n assert.equal(fooBar(), "fooXXX");\n });\n});\nI hope the Module Mocking API will be better in the future.
\n","date_published":"Wed, 02 Apr 2025 00:00:00 GMT"},{"id":"https://blog.mmyoji.com/posts/2023/07-01-improve-legacy-app-structure/","url":"https://blog.mmyoji.com/posts/2023/07-01-improve-legacy-app-structure/","title":"Improve Legacy Node.js App Structure","content_html":"\nA main project I currently tackle on adopts DDD architecture. But nobody in the\nproject understands it correctly:
\nDue to this situation, I'm now trying to improve application structure. Of\ncource, it's the best to use a framework that has strict rules about app/dir\nstructure. The project is a legacy, express.js based one, tho.
\nOne important thing is reducing roles (layers). There're many layers and\nobjects in the current architecture. Everyone confuses what/where things should\nbe put. And I realized it makes sense that Ruby on Rails adopts MVC patterns.
\nOne of the ideas will be based on NestJS approach (see\nthe tutorial).
\nWeb applications are normally the following 4 steps:
\nTo acheive this, app structure can be like this:
\napp/\n posts/\n posts.router.ts\n posts.handlers.ts\n posts.validator.ts\n posts.service.ts\nposts.router.ts handles /posts/* requests.posts.service.ts hanldes a part of 3.// posts.router.ts\nexport const postsRouter = defineRouter("/posts", (r) => {\n // GET /posts\n r.get("/", indexHandler);\n\n // GET /posts/:id\n r.get("/:id", showHandler);\n\n // GET /posts/new\n r.get("/new", newHandler);\n\n // POST /posts\n r.post("/", createHandler);\n\n // GET /posts/:id/edit\n r.get("/:id/edit", editHandler);\n\n // PATCH /posts/:id\n r.patch("/:id", updateHandler);\n\n // DELETE /posts/:id\n r.delete("/:id", destroyHandler);\n});\n\n// posts.handlers.ts\nexport const indexHandler = defineHandler(async (req, res) => {\n const options = validateSearchOptions(req.query);\n const { posts, total, cursor } = await service.fetchList(options);\n res.json({ data: { posts }, total, cursor });\n});\n\nexport const createHandler = defineHandler(async (req, res) => {\n const data = validatePost(req.body);\n const post = await service.create(data);\n res.status(201).json({ data: { post } });\n});\nYou can also arrange the structure like this:
\napp/\n posts/\n posts.router.ts\n posts.service.ts\n _index/\n index.handler.ts\n index.validator.ts\n _create/\n create.handler.ts\n create.validator.ts\nit can be like the following for more realistic monolith apps:
\napps/\n admin/ # admin.example.com/\n posts/\n posts.router.ts\n # ...\n web/ # www.example.com/\n posts/\n posts.router.ts\n # ...\nOther common layers like persistent layer, middlewares, logger, etc. is like\nthis:
\napp/\n # ...\nlib/\n entities/\n post.ts\n user.ts\n middlewares/\n not-found.middleware.ts\n server-error.middleware.ts\n repositories/\n post.repository.ts\n user.repository.ts\n logger.ts\n define-handler.ts\n define-router.ts\nI'd thought Repository pattern would be better than ActiveRecord pattern for\nseveral years. But I have to consider using AR if project members aren't skilled\nenough.
\nI'm just trying this now and don't know what I feel in future.
\n","date_published":"Sat, 01 Jul 2023 00:00:00 GMT"},{"id":"https://blog.mmyoji.com/posts/2023/03-09-apply-eslint-rules-gradually/","url":"https://blog.mmyoji.com/posts/2023/03-09-apply-eslint-rules-gradually/","title":"Apply ESLint rules gradually to your legacy project","content_html":"\nIt's not hard at all to introduce ESLint to a new\nproject, but so hard for a legacy project.
\nAlthough there are several ways to do this, I'll leave a better way for myself.
\n"rules" w/ "error""overrides" per directory w/ "warn"--max-warnings=0\noption to newly added files on CIIf eslint libs are installed in your project, you should upgrade them as far as\npossible.
\nThe rules may behave differently and have better options after the upgrade.
\n"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.\nBut the technique itself is also applicable to new config file.
\n// .eslintrc.js\n\nmodule.exports = {\n // ...\n\n rules: {\n "@typescript-eslint/no-implicit-any": ["error"],\n },\n // ...\n};\nIn this phase, your project may not have passed eslint on CI, but it's OK for\nnow.
"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.
\n// .eslintrc.js\n\nmodule.exports = {\n // ...\n\n overrides: [\n // TODO: remove listed dir after fixing the violations.\n {\n files: [\n "src/controllers/admin/**/*.ts",\n "src/controllers/web/**/*.ts",\n "src/models/**/*.ts",\n "src/lib/**/*.ts",\n ],\n rules: {\n "@typescript-eslint/no-implicit-any": ["warn"],\n },\n },\n ],\n};\nFor example,
\nno-implicit-any violations under the src/controlles/admin/*"src/controllers/admin/**/*.ts"--max-warnings=0 option to newly added files on CIThis is an optional, but very effective.
\nYou can apply stricter rules to new files. This can be done with the following\ncommand:
\n# `remotes/origin/main` can be replaced with your base branch.\n$ eslint \\\n --max-warnings=0 \\\n $(git diff --name-only --diff-filter=A remotes/origin/main HEAD)\nref:\nhttps://stackoverflow.com/a/15535048
\nIf the new files are violated against any "warn" rules, they are detected as\n"error".
You can avoid violated files are added in your project.
\n","date_published":"Thu, 09 Mar 2023 00:00:00 GMT"},{"id":"https://blog.mmyoji.com/posts/2022/09-21-migrate-to-lume/","url":"https://blog.mmyoji.com/posts/2022/09-21-migrate-to-lume/","title":"Migrate to lume","content_html":"I've migrated the static site generator for this blog from\nhugo to lume.
\n\nI had been looking for an alternative static site generator built in Deno and\ndeno_blog was a candidate. But it\ncurrently doesn't support pagination\n(p-r exists tho).
\nlume is almost the same as hugo, at least for me, it's enough. First I thought I\nneed to design entire site by myself, but I found\ntheme-simple-blog can be used\nas a plugin (like hugo theme).
\nThen I tried to migrate my blog to lume and I could. It just took less than an\nhour.
\nThe steps was like following:
\ndeno run -A https://deno.land/x/lume/init.ts) under the\nroot of the blog repo.content directory for the posts_data.ymlabout.md.gitignorethem-simple-blog pluginI've also migrated the hosting from Netlfiy to\nDeno Deploy.
\nSee the setup detail\nhere.
\nI am now satified with it :)
\n","date_published":"Wed, 21 Sep 2022 00:00:00 GMT"},{"id":"https://blog.mmyoji.com/posts/2022/09-21-next-fetch-redirect/","url":"https://blog.mmyoji.com/posts/2022/09-21-next-fetch-redirect/","title":"How to enable redirect in next-fetch","content_html":"\nnext-fetch is useful when you use\nboth SWR and Next.js API Routes.
\nBut currently the documentation is poor. I am a bit struggled with how to use\nhookResponse option in query or mutation.
⚠️ This is just for @next-fetch/swr@0.0.2 and could be changed in future\nversions.
For API routes, see\nthe doc.
\n// pages/form.tsx\n\nexport default function MyFormPage() {\n return (\n <form action="/api/simple?__handler=useMutation" method="POST">\n <input type="text" name="name" />\n <button type="submit">Submit</button>\n </form>\n );\n}\nruntime: "experimental-edge" behaves differently from runtime: "nodejs".
It returns different HTTP response headers and I will explain the detail in this\npost (although this might be wrong partially.)
\nNext.js v12.2 introduces\nEdge Runtime.
\nI'd just understood it couldn't use Node.js standard APIs and was lightweight.
\nBut I was not sure how this worked and how differed from runtime: "nodejs" and\nwondered whether this affected when choosing self-hosted.
The official document says like this:
\n\n\nEdge API Routes can stream responses from the server and run after cached\nfiles (e.g. HTML, CSS, JavaScript) have been accessed.
\n
...OK, I will test the new API routes!
\nSet experimental.runtime: "nodejs" in next.config.js
pages/api/test.ts uses runtime: "nodejs":
import { NextApiHandler } from "next";\n\nconst handler: NextApiHandler = async (_req, res) => {\n res.status(200).json({ name: "Jim Halpert" });\n};\n\nexport default handler;\npages/api/test-edge.ts uses runtime: "experimental-edge":
import { NextApiHandler } from "next";\n\nexport const config = {\n runtime: "experimental-edge",\n};\n\nconst handler: NextApiHandler = async (_req, res) => {\n // see: https://nextjs.org/docs/api-routes/edge-api-routes#json-response\n return new Response(\n JSON.stringify({\n name: "Jim Halpert",\n }),\n {\n status: 200,\n headers: {\n "Content-Type": "application/json; charset=utf-8",\n },\n },\n );\n};\n\nexport default handler;\nBoth of them returns the same response body.
\nI picked up only response headers part.
\ncurl -v http://localhost:xxx/api/test
< HTTP/1.1 200 OK\n< Content-Type: application/json; charset=utf-8\n< ETag: "16-DlZOPLD8Q/zEnYFRYsdmnqlUPWI"\n< Content-Length: 22\n< Vary: Accept-Encoding\n< Date: Thu, 30 Jun 2022 11:42:50 GMT\n< Connection: keep-alive\n< Keep-Alive: timeout=5\ncurl -v http://localhost:xxx/api/test-edge
< HTTP/1.1 200 OK\n< Content-Type: application/json; charset=utf-8\n< Date: Thu, 30 Jun 2022 11:43:39 GMT\n< Connection: keep-alive\n< Keep-Alive: timeout=5\n< Transfer-Encoding: chunked\nexperimental-edge runtime:
ETag, Content-Length, and Vary headersTranfer-Encoding: chunked headerTransfer-Encoding: chunked sends HTTP repsonse as chunk (or stream)\naccording to\nMDN doc.
Content-Length is omitted from the doc.Vary: Accepct-Encoding is omitted for this endpoint\nbecause Transfer-Encoding is specified (chunks are always sent).ETag is dropped, I guess, might be that the endpoint could not\nend in a single request.Again, my understanding for HTTP is not enough and this post might be wrong.\nPlease check correct sources by yourself.
\nI tried WSLg because I might need to run\nchromedriver for next job.
I had ever struggled and gave up running chromedriver in normal WSL(WSL2)\nenvironment before, so I thought this was a good opportunity.
The following step is limited for WSL2 +\nPengwin distro that I've been\nusing.
\n\npengwin-setup update\n\n# Open setup dialog\n# and select [GUI], then install necessary packages.\npengwin-setup\nAfter package installation, restart WSL (or restart Windows).
\nref: https://github.com/microsoft/wslg#install-and-run-gui-apps
\ncd /tmp\nsudo wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb\nsudo dpkg -i google-chrome-stable_current_amd64.deb\nsudo apt install --fix-broken -y\nsudo dpkg -i google-chrome-stable_current_amd64.deb\n\n# Start Google Chrome app in Linux GUI for test\ngoogle-chrome\nref: https://tecadmin.net/setup-selenium-with-chromedriver-on-debian/
\n# 1. check your google chrome version on WSLg\n# 2. Download the same version of chromedriver with google-chrome\n# http://chromedriver.storage.googleapis.com/index.html\n# The version was 102.0.5005.61 this time.\n\ncd /tmp\nwget http://chromedriver.storage.googleapis.com/102.0.5005.61/chromedriver_linux64.zip\nunzip chromedriver_linux64.zip\nsudo mv chromedriver /usr/bin/chromedriver\nsudo chown root:root /usr/bin/chromedriver\nsudo chmod +x /usr/bin/chromedriver\nRun the following script when you want to test.
\nref: https://www.npmjs.com/package/selenium-webdriver
\n/**\n * $ npm init -y\n * $ npm install selenium-webdriver\n * $ vim main.js\n */\n\n// main.js\nconst { Builder, Browser, By, Key, until } = require("selenium-webdriver");\n\n(async function main() {\n const driver = await new Builder().forBrowser(Browser.CHROME).build();\n try {\n await driver.get("http://www.google.com/ncr");\n await driver.findElement(By.name("q")).sendKeys("webdriver", Key.RETURN);\n await driver.wait(until.titleIs("webdriver - Google Search"), 1000);\n // Replace the string with 'webdriver - Google 検索' when your language setting is Japanese.\n } finally {\n await driver.quit();\n }\n})();\n\n// node main.js\nWhen you want to disable all inputs in form after submitting, you can use\nfieldset for the purpose.
<form action="#">\n <fieldset disabled>\n <!-- like this -->\n <legend>Sign in</legend>\n\n <label for="email">Email</label>\n <input id="email" name="email" type="email">\n\n <label for="password">Password</label>\n <input id="password" name="password" type="password">\n\n <input type="submit">\n <!-- button is also disabled\n <button>Submit</button>\n -->\n </fieldset>\n</form>\n