DEV Community: takahiro hashito

My unattended bot once pushed someone else's work in progress. So I banned git add -A

takahiro hashito — Wed, 05 Aug 2026 13:35:02 +0000

Background

I run a fleet of small sites that update themselves twice a day.
A scheduled agent regenerates content, builds, deploys, and commits the result.

For a long time that commit step was git add -A.
It was the obvious choice, and it worked right up until it didn't.

What went wrong

One morning the run committed ten files that had nothing to do with it.
They were half-finished changes I had left in the working tree from a different task the night before.

The agent did not know that.
git add -A stages everything, including work in progress, and the run pushed it straight to origin/main.

Nobody was watching.
That is the part that matters: an interactive git add -A is recoverable because you see the diff.
An unattended one is not, because the first person to notice is whoever pulls a broken intermediate state hours later.

The rule I settled on

The commit step now reads an allow-list and stages only paths that match it.
The config looks roughly like this, keyed by scope:

{
  "defaultSiteAllow": ["data/", "public/"],
  "scopes": {
    "fleet": [
      "automation/log/",
      "automation/state.json",
      "automation/issues.json"
    ]
  }
}

A trailing slash means "everything under this directory", anything else is an exact match.
Each site gets data/ and public/ by default, because those are the generated artifacts a content run is supposed to produce.

Everything else is left alone.
Not committed, and — this is the important half — not deleted or reverted either.

Three outcomes, not two

The interesting design decision was the exit code.

A run that finds unexpected changes could fail, but that would stop content generation for a reason the machine cannot fix.
It could also silently ignore them, which is how you end up with a working tree nobody ever looks at.

So there are three outcomes:

exit 0 — everything staged was in the allow-list
exit 3 — the commit succeeded, and there were changes outside the allow-list
exit 4 — the commit succeeded but the push never reached origin

Exit 3 is a success for the run and a signal for me.
The unexpected paths get appended to that day's log automatically, under a heading I can grep for.

Here is what today's run actually reported:

{
  "committed": true,
  "pushed": true,
  "commit": "412959d",
  "note": "想定外の変更を検出したためコミットから除外しました（作業ツリーには残っています）。",
  "exitCode": 3
}

The excluded paths were a Python script from an unrelated feature branch and some CSS in a dashboard file.
Both are things I am actively editing.
Under the old behaviour, both would now be on main.

When you do want to include something

Sometimes the run legitimately needs to commit code — for example when it fixes a bug it found in its own tooling.
For that there is an explicit flag:

node automation/run.js git:commit --scope fleet \
  --message "fix(preflight): detect uncommitted build inputs" \
  --allow "automation/scripts/common/preflight.js,test/preflight.test.js" \
  --push

--allow takes a comma-separated list of paths that get added to the allow-list for this one commit.
The point is not that it is hard to type.
The point is that the decision to include code now appears in the command, so it shows up in the shell history and in the log.

There is a second guard behind this one: even a path that matches the allow-list is skipped if it has a code extension, unless --allow names it.
That exists because some scopes list broad directories, and a broad directory will eventually contain a .js file that nobody meant to ship.

What I would tell past me

Reverting or stashing the unexpected changes would have been worse than committing them.
An automated job destroying uncommitted human work is a much harder failure to recover from than one that leaves a mess and tells you about it.

So the rule I would give anyone automating commits: stage an explicit list, leave everything else exactly where it is, and make "there was something else" a distinct, visible outcome.
Silence is the only option that is actually dangerous.

One of the sites this runs against is https://cve.autoarticles.net if you want to see what the output looks like.

This article is about my own side project. It was written with AI assistance.

Implementing UUID v7 with nothing but crypto.getRandomValues()

takahiro hashito — Sun, 02 Aug 2026 13:44:31 +0000

Introduction

I run a site of small browser-only tools. Each one does a single thing, loads no external resources, and sends nothing to a server.

I recently added a UUID generator. Version 4 is a one-liner via crypto.randomUUID(), so there was nothing to build. Version 7 is the interesting one: it is still not in the standard API, and since the site loads no third-party scripts by policy, I had to write it myself.

UUID v7 puts a Unix millisecond timestamp in the leading 48 bits and fills the rest with randomness. That means sorting the strings lexicographically sorts them by creation time, which is the whole point of the version.

The layout

The 128 bits break down like this:

 0                   48      52          64
 +-------------------+-------+-----------+------------------------+
 | unix_ts_ms (48)   | ver(4)| rand_a(12)| var(2) | rand_b (62)   |
 +-------------------+-------+-----------+------------------------+

Only two fields are fixed by the spec:

version: bits 48–51 must be 0111 (7)
variant: bits 64–65 must be 10 (RFC 4122 family)

Everything else can be random. So the job is: pack the timestamp at the front, fill the rest with randomness, then overwrite exactly two spots.

The implementation

Here is the whole thing. We build a 16-byte Uint8Array and fill it front to back.

function uuidv7() {
  const bytes = new Uint8Array(16);

  // (1) Leading 48 bits = Unix milliseconds, most significant byte first
  const ms = BigInt(Date.now());
  for (let i = 0; i < 6; i++) {
    bytes[i] = Number((ms >> BigInt(8 * (5 - i))) & 0xffn);
  }

  // (2) Fill the remaining 10 bytes with randomness
  crypto.getRandomValues(bytes.subarray(6));

  // (3) version = 7: clear the high nibble, then set 0x70
  bytes[6] = (bytes[6] & 0x0f) | 0x70;

  // (4) variant = 10xxxxxx: clear the top 2 bits, then set 0x80
  bytes[8] = (bytes[8] & 0x3f) | 0x80;

  const hex = [...bytes].map((b) => b.toString(16).padStart(2, "0")).join("");
  return `${hex.slice(0,8)}-${hex.slice(8,12)}-${hex.slice(12,16)}-${hex.slice(16,20)}-${hex.slice(20)}`;
}

bytes is the buffer under construction and ms is the current time in milliseconds. Date.now() needs about 41 bits, so it fits comfortably in the 48-bit field. It overflows some time around the year 10889.

The important part is the ordering of steps (3) and (4). We fill with randomness first, then clear only the target bits, then set the fixed value.

bytes[6] & 0x0f zeroes the high nibble so that | 0x70 can write 0111 into it. Both halves are required. If you skip the mask and write bytes[6] | 0x70, a random byte of 0x8? yields a version nibble of 1111 (15) instead of 7.

What tripped me up

My first version set the version bits before filling in the randomness:

// broken
bytes[6] = 0x70;
crypto.getRandomValues(bytes.subarray(6));  // <- overwrites 0x70

The output still looks like a UUID, so eyeballing the results tells you nothing. It is 36 hex characters with dashes in the right places either way.

I only caught it when I wrote a test asserting the version nibble. Character index 14 of the string is the version digit.

// the broken version passes roughly 1 time in 16
for (let i = 0; i < 1000; i++) {
  assert.equal(uuidv7().charAt(14), "7");
}

Because it fails probabilistically, running the test once and seeing it pass makes you think it is fixed. It took a thousand iterations to fail reliably.

The other easy mistake is byte order in the timestamp. Pack it little-endian and the low-order millisecond byte lands at the front, so lexicographic order stops matching time order. That is the only reason to choose v7 in the first place, so getting this backwards silently removes the benefit. Pack most significant byte first.

One caveat worth stating: UUIDs generated within the same millisecond have no guaranteed order among themselves, since the comparison falls through to the random bits. If you need strict monotonicity, you need a counter within the millisecond. For database primary keys it usually does not matter, because millisecond granularity is enough to keep inserts landing at the tail of the B-tree.

The working tool is here. It runs entirely in the browser, so generated IDs are never transmitted anywhere.

https://hashitosystem.com/tools/uuidgen/

Wrapping up

The recipe is three steps: pack the timestamp most significant byte first, fill the rest with randomness, then mask and set exactly two fields.

When you hand-roll a format that fixes bit positions by spec, keep the order fill, mask, set. Setting before filling gives you a bug that only shows up part of the time, which is exactly the kind that survives a test you ran once.

This article is about my own side project. It was written with AI assistance.

A dependency-free build.js: assembling a static site from JSON data

takahiro hashito — Fri, 31 Jul 2026 13:45:08 +0000

Intro

I run several small information sites that get new data appended every day. I started with a static site generator, but as the number of sites grew, I spent more and more time on things unrelated to the content: framework version bumps, plugin incompatibilities, slow builds. So I switched everything to a dependency-free build.js (Node standard library only) that assembles public/ HTML from data/*.json.

What I learned is that static site generation splits cleanly into three layers — data, template, validation — and once you do that, you can keep growing without a framework. This post walks through that design.

The big picture

The layout is simple.

data/site.json        … site config and categories
data/articles.json    … an array of articles (one object per article)
build.js              … reads data, renders HTML via template strings, writes public/
public/               … the output (this is what gets deployed)

build.js does exactly three things:

Read the data (JSON.parse(fs.readFileSync(...)))
Validate (reject broken articles — more below)
Apply templates (build HTML with template strings, fs.writeFileSync)

The only dependencies are Node's built-in fs and path. There is no npm install, so any machine can clone the repo and run node build.js immediately.

The core of the implementation

The templates are neither JSX nor a template engine — just plain template strings. Rendering one article to HTML is only this:

function renderArticle(a, site) {
  return `<!DOCTYPE html>
<html lang="ja"><head>
<meta charset="utf-8">
<title>${esc(a.title)} | ${esc(site.name)}</title>
<meta name="description" content="${esc(a.summary)}">
<link rel="canonical" href="${site.canonical}/articles/${a.slug}/">
<script type="application/ld+json">${JSON.stringify(breadcrumb(a, site))}</script>
</head><body>
<h1>${esc(a.title)}</h1>
${a.synopsis.split("\n").map(p => `<p>${esc(p)}</p>`).join("\n")}
</body></html>`;
}

The key point: every value that goes into meta must pass through esc(). Template strings do raw string interpolation, so letting <, >, & through produces broken HTML or double-escaping. Fixing this in one function means no accident, no matter how much the data grows.

Listings, categories, tags, sitemap, and RSS are all generated with the same "map the data, fill a template string" pattern. Shared header and footer are extracted into functions and injected into every page. A framework's "layout inheritance" turned out to be just a function call.

The gotcha

Since data is appended unattended every day, the scariest thing is broken data getting published as-is. So I put validation at the top of build.js and stop the build (fail-closed) if any article fails the check.

function validateArticles(articles) {
  const errors = [];
  const seen = new Set();
  for (const a of articles) {
    if (!a.slug || seen.has(a.slug)) errors.push(`duplicate/missing slug: ${a.slug}`);
    seen.add(a.slug);
    if (!a.title || !a.summary) errors.push(`${a.slug}: missing title/summary`);
    // raw < > left in meta (detects a template accident)
    if (/[<>]/.test(a.title)) errors.push(`${a.slug}: raw tag in title`);
  }
  if (errors.length) {
    console.error(errors.join("\n"));
    process.exit(1);       // stop here; never deploy broken HTML
  }
}

Putting the check inside the build rather than in a separate lint tool is what made it work. "The build passed" becomes an invariant that means "it is safe to publish", so "the build succeeded but the content is broken" can't happen even when nobody is watching.

One more gotcha: tag-page file names. If you use a Japanese tag directly as a file name, the links need percent-encoding. Decide "file name is raw UTF-8, href is encoded" up front, or links break depending on the environment.

The result

Here is one of the sites actually running this way: https://ocha.autoarticles.net

I run several sites on the same skeleton. Adding a new one is just preparing data/ and copying the listing generation in build.js.

Takeaways

Static site generation splits into three layers — data, template, validation — and stays maintainable without a framework.
Plain template strings are enough. Just fix meta escaping in one function.
Put validation inside the build so that "the build passed" means "it is safe to publish". That is what makes unattended operation safe.

This article is about my own side project. It was written with AI assistance.

One entry point for 50 automation scripts (and one permission rule)

takahiro hashito — Fri, 24 Jul 2026 13:45:50 +0000

Background

I run a couple of dozen small sites on autopilot. Along the way I accumulated close to fifty small maintenance scripts: decide which site is due for an update today, lint the built HTML for emoji, write results back to a state file, track sitemap indexing, and so on. None of them need an LLM. They are plain deterministic Node scripts.

They lived in a tree under automation/scripts/, each with its own path. That was fine until I started invoking them from an agent running unattended. Every distinct command shape needed its own permission rule, and the moment one was missing the batch stopped at a prompt and sat there until morning.

How it works

Instead of tuning the permission rules, I changed the shape of the commands. All the scripts now sit behind a single entry point.

node automation/run.js <op> [--json '<JSON>'] [--flag value]

run.js looks the op name up in a table and spawns the matching script. Nothing else.

run.js  ── OPS table ──> scripts/whats-due.js
                     └─> scripts/common/emoji-lint.js
                     └─> scripts/seo/orphan-check.js
                         ... (around 50 ops today)

One command shape means one permission rule: node automation/run.js:*.

Implementation

The core is the lookup table, and the important part is what happens when the lookup fails.

const OPS = {
  "whats-due": "whats-due.js",
  "update-state": "common/update-state.js",
  "emoji-lint": "common/emoji-lint.js",
  "seo:orphan": "seo/orphan-check.js",
  // ...
};

const rel = OPS[op];
if (!rel) {
  process.stderr.write(
    `unknown op: ${op}\n利用可能: ${Object.keys(OPS).join(", ")}\n`,
  );
  process.exit(2);
}

There is no path built from user input. An op that is not in the table exits with code 2 and prints the list of valid ops. So the effective permission surface is the table, which lives in the repository and can be reviewed.

The second piece is expanding a JSON object into flags, so that every call has the same shape no matter how many arguments the target script takes.

function jsonToArgv(obj) {
  const out = [];
  for (const [k, v] of Object.entries(obj || {})) {
    if (k === "_") {                       // positional arguments pass through
      (Array.isArray(v) ? v : [v]).forEach((x) => out.push(String(x)));
      continue;
    }
    if (v === false || v === null || v === undefined) continue;
    if (v === true) out.push(`--${k}`);                          // {"deploy":true} -> --deploy
    else if (Array.isArray(v)) out.push(`--${k}`, v.join(","));  // {"episodes":[1,2]} -> --episodes 1,2
    else out.push(`--${k}`, String(v));
  }
  return out;
}

Which makes the call sites look like this:

node automation/run.js emoji-lint --json '{"ext":"html","_":["public"]}'
node automation/run.js update-state --json '{"site":"cve-watch","added-cves":["CVE-2026-1"]}'

Gotchas

I nearly added automatic camelCase to kebab-case conversion, so that addedCves would become --added-cves. I backed that out. The flag names of the target scripts are chosen individually and a mechanical rule does not always match them. When the conversion misses, the flag is silently dropped instead of failing, and a silent drop is the worst failure mode for an unattended batch. Writing the exact flag name is slightly more work and it fails loudly when you get it wrong.

The other trap was on my side rather than the code's. Once the entry point existed, it was tempting to route everything through it. I drew a line: operations that publish, spend money, touch DNS or write secrets do not get an op. A narrow entry point stops meaning anything if you can do everything behind it.

The result

One of the sites this drives: https://cve.autoarticles.net

Its daily update runs entirely through run.js ops, from fetching vulnerability data to the emoji lint and the state write-back.

What I actually built was a table and a thin dispatcher. The payoff was not new capability but a smaller surface: one permission rule instead of many, and the same command shape every time. When something has to run unattended, removing entry points beats adding features.

This article is about my own side project. It was written with AI assistance.

Implementing UUID v7 by hand: time-sortable primary keys (and the same-millisecond trap)

takahiro hashito — Wed, 22 Jul 2026 23:17:02 +0000

Random UUID v4 makes a poor primary key: values land all over the index, so B-tree inserts scatter across pages and page splits go up. UUID v7 puts a millisecond timestamp in the leading bits (standardized in RFC 9562), so generation order equals sort order and you get locality back.

I needed a UUID generator that runs entirely in the browser, and while building it I implemented v7 by hand instead of pulling in a library. Here is the layout, the implementation, the trap I hit, and when each version is actually the right choice.

The v7 layout

The 128 bits break down like this:

| 48bit unix_ms | 4bit ver(=7) | 12bit rand_a | 2bit variant | 62bit rand_b |

The first 48 bits are the Unix timestamp in milliseconds, big-endian. Then the version (7) and variant bits, and everything else is random. The random part must come from a cryptographic source (crypto.getRandomValues) — not Math.random().

Implementation: putting the bits in the right place

The whole job is "pack the timestamp into the first six bytes, most significant byte first, then overwrite the version and variant nibbles."

function rnd(n){ const a = new Uint8Array(n); crypto.getRandomValues(a); return a; }
function hex(b){ let s=''; for(const x of b) s += ('0'+x.toString(16)).slice(-2); return s; }

function uuidV7() {
  const ts = Date.now();          // 48-bit millisecond timestamp
  const b = rnd(16);
  // 48-bit big-endian millisecond timestamp (top six bytes)
  b[0] = (ts / 0x10000000000) & 0xff; // ts >> 40
  b[1] = (ts / 0x100000000)   & 0xff; // ts >> 32
  b[2] = (ts / 0x1000000)     & 0xff; // ts >> 24
  b[3] = (ts / 0x10000)       & 0xff; // ts >> 16
  b[4] = (ts / 0x100)         & 0xff; // ts >> 8
  b[5] =  ts                  & 0xff;
  b[6] = (b[6] & 0x0f) | 0x70;    // version 7
  b[8] = (b[8] & 0x3f) | 0x80;    // variant (10xx)
  const h = hex(b);
  return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}

The detail worth remembering: shift the digits down with division, not with >>. ts >> 40 does not work, because JavaScript's bitwise operators coerce their operands to 32 bits and a 48-bit value gets mangled. Division followed by & 0xff is safe.

For v4, by the way, don't hand-roll anything if the platform gives you the standard API — it is both faster and safer.

function uuidV4() {
  if (crypto.randomUUID) return crypto.randomUUID(); // one call where it's supported
  const b = rnd(16); b[6] = (b[6]&0x0f)|0x40; b[8] = (b[8]&0x3f)|0x80;
  const h = hex(b);
  return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}

The trap: ordering is not guaranteed within a millisecond

If two IDs are generated in the same millisecond, their leading 48 bits are identical and everything after that is random — so their relative order is arbitrary. If you assume "generation order == strictly ascending", a burst of IDs will quietly break that assumption.

When you do need strict monotonicity, use the 12-bit rand_a field as a counter: increment it within the same millisecond, and reseed it when the millisecond changes.

let lastMs = 0, seq = 0;
function uuidV7Monotonic() {
  const ts = Date.now();
  if (ts === lastMs) seq = (seq + 1) & 0x0fff; // same ms: +1 (12 bits)
  else { lastMs = ts; seq = rnd(2)[0] & 0x0fff; } // new ms: start from random
  // ...store seq in the low 12 bits of b[6..7], overwriting version = 7...
}

If "roughly time-ordered" is good enough for your use case, plain random is fine. The design decision to make up front is simply whether you need strict monotonicity — not which implementation looks cleverer.

Checking it instead of trusting the spec

I measured the following in both Node and the browser rather than assuming the spec held:

Are the version and variant bits actually set? (u[14] === '7', and u[19] is one of 8, 9, a, b.)
Do two IDs generated across a millisecond boundary always sort ascending?
Generate 1000 IDs inside a single millisecond — does the plain implementation break ascending order, and does the counter version hold?

Reproducing the failure yourself, on purpose, is what makes the edge of the trap visible. "The spec says it should" is not the same as having seen it.

v4 vs v7 vs ULID

	Time-sortable	Locality	Standard	In one line
UUID v4	No	Low	RFC 9562	Fully random. Spreads well, hard on indexes
UUID v7	Yes (ms granularity)	High	RFC 9562	Good primary key. Drops into an existing UUID column
ULID	Yes	High	De facto	26-char Base32. Worth a look if you don't need UUID compatibility

If you are using UUIDs as primary keys, v7 is worth considering first. In practice the big win is that it fits your existing uuid / UUID column type unchanged — no migration of the column, just of the generator.

The result

I published the generator as a browser tool: it does v4 and v7, with options for count, hyphens, and uppercase. Generation happens in the page and nothing is sent to a server: https://hashitosystem.com/tools/uuidgen/

Wrap-up

v7 is the right fit for "I want roughly time-ordered keys with good locality." The implementation is just splitting the timestamp into bytes with division and overwriting the version/variant nibbles. The one caveat to internalize: ordering within a single millisecond is not guaranteed, so pair it with a counter if you need strict monotonicity. Get that one point right and it is safe to use.

This article is about my own side project. It was written with AI assistance.

Expiring Content: Put the Deadline in the Data, Not the Prose

takahiro hashito — Wed, 22 Jul 2026 23:16:55 +0000

Introduction

I run several sites that publish time-limited information: Kindle manga sales, grocery and household deals. Everything on them expires.

That creates a structural weakness. Expired deals left on the page erode trust in the whole site. A reader clicks a link labeled "through July 31" and lands on a full-price page. After that happens a couple of times, they stop coming back.

Removing expired entries by hand does not scale; the more articles you have, the worse it gets. So I moved the deadline into the data and let the build decide what to show.

Architecture

Each article carries metrics.deadline in its JSON, and build.js computes the days remaining at generation time.

articles.json
  └ metrics.deadline: "2026-07-31"
        ↓  build.js
   daysUntil(deadline, survey date)
        ↓
   ┌─ left <  0 → excluded from listings; article shows "may have ended"
   ├─ left == 0 → "today only" (emphasized)
   ├─ left <= 3 → "N days left" (emphasized)
   └─ left >  3 → "N days left"

The key design decision is that the reference date is not today but the date the article was last verified. More on that below.

The core of the implementation

Computing days remaining is all there is to it.

// Parse an ISO date (YYYY-MM-DD) as JST and return days remaining from the
// survey date. Expired is negative, same day is 0. The base is the survey
// date (the article's last verification date), not today.
function daysUntil(deadlineIso, baseIso) {
  const base = new Date((baseIso || surveyDate()) + "T00:00:00+09:00");
  const dl = new Date(deadlineIso + "T00:00:00+09:00");
  return Math.round((dl.getTime() - base.getTime()) / 864e5);
}

Spelling out +09:00 is the point. new Date("2026-07-31") parses as UTC, so running in JST shifts the result by nine hours and the date lands a day off. That surfaces as "today only" appearing a day early. If your dates carry a timezone, pin it at parse time.

The expiry check:

// A sale is ended only if it has a deadline and that deadline has passed
// relative to the survey date. Articles with no deadline data are never
// marked as ended (do not fabricate an ended state).
function isEnded(a) {
  const dl = a && a.metrics && a.metrics.deadline;
  return !!dl && daysUntil(dl) < 0;
}

As the comment says, articles without a deadline are deliberately not treated as ended. Displaying "this has ended" for something whose deadline is merely unknown would state something I have not verified. Deciding what not to render when data is missing is part of the spec for this kind of site.

Excluding them from listings is one filter.

// Ended sales: hidden from listings (top/category/tag/related/RSS/sitemap)
// but kept on the article page and in site search, so they stay reachable
// by direct URL.
function listedArticles() {
  return articles.filter((a) => !isEnded(a));
}

Note that this filters rather than deletes. The reason follows.

Rendering branches on days remaining:

const left = daysUntil(m.deadline);
let leftTxt = "", cls = "fact-until";
if (left < 0)        { leftTxt = "may have ended";   cls = "fact-until fact-expired"; }
else if (left === 0) { leftTxt = "today only";       cls = "fact-until fact-urgent";  }
else if (left <= 3)  { leftTxt = `${left} days left`; cls = "fact-until fact-urgent"; }
else                 { leftTxt = `${left} days left`; }

What bit me

Using "today" as the reference date makes the article assert things I never checked.

Initially daysUntil was based on the execution date. That looks natural, and it breaks.

Deal information is written on the day the source was verified. Suppose on July 20 I confirm "through July 31". Rendering that in August correctly says "expired". The failure is the other direction: the deadline itself may have changed at the source. If it was extended or cut short, my data still says July 20's version. Presenting "5 days left" as today's information asserts a fact I have not verified.

So the base became the survey date.

const base = new Date((baseIso || surveyDate()) + "T00:00:00+09:00");

Now days remaining means "how many days were left at the time of verification". The wording follows: "as of the source and verification date, listed as running through July 31." Anything past the deadline reads "may have ended", because whether it actually ended is something I did not check.

Second: deleting expired articles kills URLs.

An earlier version dropped expired entries from generation entirely. That was wrong for both SEO and readers. Externally linked URLs began returning 404, and search traffic had nowhere to land.

Now they are removed from listings, RSS, and the sitemap, but kept on the article page and in site search. New discovery paths no longer surface them, while existing links keep working. A page that says "this sale may have ended" serves a reader far better than a 404.

The result

One of the sites running this: https://manga.autoarticles.net

It aggregates Kindle manga sales, each article showing a days-remaining badge. Expired entries drop out of the listings automatically.

Conclusion

If you handle time-limited information, put the deadline in the data, not the prose. Text that merely says "through July 31" is unreadable to the build, so the operation falls back to human labor.

And the choice of reference date determines what you are allowed to claim. Today's date produces assertions; the verification date produces "here is what was confirmed, and when". Pick the base that matches how certain your information actually is — that was the part of this implementation I thought hardest about.

This article is about my own side project. It was written with AI assistance.

Enforcing Content Tone With a Lint That Fails the Build

takahiro hashito — Wed, 22 Jul 2026 23:16:46 +0000

Introduction

I run about twenty static sites on an automated pipeline. Article data lives in JSON, and a dependency-free build.js emits the HTML. Since updates run unattended, most of the writing is done by machines too.

That created a problem I did not anticipate: tone drifted. I had a rule that these sites use no emoji. Yet every run slipped one in somewhere. A heading here, an FAQ answer there. I would remove them, and the next day they showed up somewhere else.

Trying to hold a style rule in place through review does not scale. So I turned it into a lint that fails the build.

Architecture

The shape is simple: walk the files, report any line containing an emoji, and exit non-zero if there is even one.

update data
   ↓
emoji-lint  ← exits 1 if a single emoji is found
   ↓
build.js (generate site)
   ↓
deploy

The important part is failing via the exit code. A lint that only prints warnings does not get read. Once the following steps stop running, the rule starts to mean something.

The core of the implementation

It is one regular expression plus a loop over every line.

// Main ranges for emoji, pictographs, regional indicators, and variation selectors.
// (Arrows and similar symbols used in real content are deliberately excluded
//  to avoid false positives.)
const EMOJI_RE =
  /[\u{1F000}-\u{1FAFF}\u{2600}-\u{27BF}\u{2B00}-\u{2BFF}\u{1F1E6}-\u{1F1FF}\u{FE0F}\u{200D}\u{2049}\u{203C}\u{2122}\u{2139}]/u;

Range selection followed a deliberate policy. \u{2600}-\u{27BF} contains pictographs, but banning the whole block also catches arrows and other symbols. False positives on characters people legitimately use are how a lint ends up disabled. I optimized for zero false positives and accepted that a few cases slip through to human review.

Including \u{FE0F} (variation selector) and \u{200D} (ZWJ) matters. Emoji are not always a single code point; many are composed as "base character + FE0F" or "emoji + ZWJ + emoji". Matching on the selectors catches that whole family of compositions.

Findings are reported as JSON with line numbers.

const lines = text.split("\n");
lines.forEach((line, i) => {
  if (EMOJI_RE.test(line)) {
    findings.push({ file, line: i + 1, text: line.trim().slice(0, 200) });
  }
});

emit({ ok: findings.length === 0, count: findings.length, findings });
process.exit(findings.length === 0 ? 0 : 1);

Truncating text at 200 characters keeps a single long line from flooding the log. File and line number are enough to locate the problem.

What bit me

An extension-matching bug made the lint silently pass everything.

I added --ext to narrow the scan. path.extname() returns the extension with a leading dot, like ".html". But on the calling side you naturally want to write --ext html, without one. Compare those directly and:

// Bug: with --ext html, nothing matches ".html", so zero files are scanned
if (!exts || exts.includes(path.extname(target))) out.push(target);

exts was non-empty but matched nothing, so zero files scanned, zero findings, ok: true. The lint kept reporting success. Emoji were getting through while it said everything was fine.

The fix is to normalize the input.

const exts = args.ext
  ? String(args.ext)
      .split(",")
      .map((e) => e.trim())
      .filter(Boolean)
      .map((e) => (e.startsWith(".") ? e : `.${e}`))
  : null;

The lesson: a lint that cannot distinguish "found nothing" from "looked at nothing" is dangerous. Printing the number of files scanned alongside a pass would have surfaced the empty scan immediately. I now read the count together with the findings.

One more thing: skipping node_modules and .git is essential, or you drown in hits from dependency READMEs.

for (const name of fs.readdirSync(target)) {
  if (name === "node_modules" || name === ".git") continue;
  out.push(...listFiles(path.join(target, name), exts));
}

The result

One of the sites running on this pipeline: https://cve.autoarticles.net

It covers vulnerability information and uses no emoji at all. A serious subject deserves a serious presentation, and that presentation is now enforced mechanically.

Conclusion

Consistency in tone and style will always leak if you rely on review. If a rule can be decided mechanically, write the code that decides it and fail on violations.

But the lint itself can break and still report success. The extension bug was exactly that. Verifying that a check can detect violations matters as much as verifying that it is actually looking. After writing a lint, deliberately introduce a violation once and confirm it fails.

This article is about my own side project. It was written with AI assistance.