DEV Community: hiro@

When Wrangler-generated types collide with Next.js DOM types

hiro@ — Sat, 05 Sep 2026 01:35:37 +0000

This article is an English translation of the original Japanese article.

I deploy a Next.js application to Cloudflare Workers through @opennextjs/cloudflare. After running wrangler types to type the D1 binding, TypeScript errors appeared across the application.

error TS18046: 'body' is of type 'unknown'.
error TS2339: Property 'name' does not exist on type 'object'.

The main symptom was that request.json() suddenly returned unknown. In my setup, Wrangler's generated runtime definitions collided with the DOM types used by Next.js. I fixed it by removing the generated file and writing a small declaration file that uses import type. The exact behavior can vary with versions and tsconfig scope, so this article describes the configuration where I reproduced it.

What happened

By default, wrangler types creates worker-configuration.d.ts. It contains both the binding Env interface and the complete Workers runtime definitions. Global types such as Request, Response, and Body all enter the project.

In the Workers runtime types, Body#json() returns Promise<unknown>. In the DOM library used by Next.js, it returns Promise<any>. Once the generated runtime globals joined the same TypeScript project, every await request.json() in a Route Handler became unknown, and accesses such as body.name failed type checking.

Those Workers types are appropriate in a Worker-only project. A Next.js application also needs the DOM library, and both libraries define the same global names.

Attempt: `--include-runtime=false`

Wrangler can exclude runtime types from its generated output.

wrangler types cloudflare-env.d.ts --env-interface CloudflareEnv --include-runtime=false

The resulting file contains only the environment interface.

// Generated cloudflare-env.d.ts
interface CloudflareEnv {
  DB: D1Database;
  ASSETS: Fetcher;
}

This looked promising, but it introduced another error.

error TS2552: Cannot find name 'D1Database'. Did you mean 'IDBDatabase'?

D1Database and Fetcher are global names supplied by the runtime definitions. Including the runtime caused the DOM collision, while excluding it left the generated interface unable to resolve those names.

Fix: a handwritten declaration file with `import type`

I stopped generating the file and imported only the binding types I needed.

npm i -D @cloudflare/workers-types

// cloudflare-env.d.ts, written manually
import type { D1Database, Fetcher } from "@cloudflare/workers-types";

declare global {
  interface CloudflareEnv {
    DB: D1Database;
    ASSETS: Fetcher;
  }
}

export {};

This works for three reasons:

Types brought in with import type stay scoped to this module. The Workers versions of Request and Response do not leak into the global namespace or collide with the DOM library.
declare global exposes only CloudflareEnv. getCloudflareContext() from @opennextjs/cloudflare returns its env using this interface, which gives env.DB the D1Database type.
The import already makes the declaration file a module. The final export {} is included to make that status explicit, but it is not required.

The binding type is then available at the call site.

import { getCloudflareContext } from "@opennextjs/cloudflare";

function getDb() {
  return getCloudflareContext().env.DB; // inferred as D1Database
}

Tradeoff

The handwritten file must be updated when a binding is added. This gives up the main benefit of wrangler types, which generates an interface from wrangler.jsonc.

For my application, the bindings change infrequently and consist of one D1 database plus static assets. Maintaining a few lines in one file has not been a problem. A larger project with many bindings could generate CloudflareEnv and then transform the output to add scoped type imports.

Summary

Wrangler's generated file can include Workers runtime globals that collide with the DOM library in a Next.js project. A sudden unknown return type from json() is one symptom.
In my configuration, --include-runtime=false left binding types such as D1Database unresolved.
A handwritten declaration file using import type and declare global types the bindings without adding Workers request and response globals.

Worker-only projects do not have the same DOM coexistence problem, which made the cause harder to find.

Environment

@opennextjs/cloudflare 1.20, Wrangler 4.113, and @cloudflare/workers-types 5.x
Next.js 16 App Router. Next.js 15 can have the same type structure

Removing handwritten API types with tRPC RouterInputs and RouterOutputs

hiro@ — Fri, 04 Sep 2026 01:34:22 +0000

This article is an English translation of the original Japanese article.

tRPC can derive every procedure's input and output types from the router definition. The UI does not need to repeat the server response as an interface such as interface Schedule { ... }.

I use tRPC v11 in a monorepo containing a Next.js web app and an Expo mobile app. The web side defines these two helper types:

import { type inferRouterInputs, type inferRouterOutputs } from "@trpc/server";
import { type AppRouter } from "~/server/api/root";

/** Input types for every procedure */
export type RouterInputs = inferRouterInputs<AppRouter>;
/** Output types for every procedure */
export type RouterOutputs = inferRouterOutputs<AppRouter>;

These are the patterns I use most often.

1. Get the item type from a list

A findMany-style procedure returns an array. Indexing it with [number] extracts the element type.

type Schedule = RouterOutputs["schedule"]["list"][number];

Changing the server-side select or include automatically updates this type.

2. Use the output type for child component props

When a list page passes data to a child component, its props can come from the same output type.

type Props = {
  schedule: RouterOutputs["schedule"]["list"][number];
  onSelect: (id: string) => void;
};

function ScheduleCard({ schedule, onSelect }: Props) {
  // schedule.title and the other fields are inferred
}

The API response and component props now have the same source. If the server response changes, TypeScript reports the mismatch in the child component too.

3. Index into nested properties

For responses that include relations, regular indexed access reaches the nested type.

type Member = RouterOutputs["membership"]["listByOrg"][number];
type MemberUser = Member["user"]; // Relation loaded through `with`

4. Build form values from `RouterInputs`

Deriving create and update form values from the mutation input avoids maintaining a second type beside the Zod schema.

type CreateScheduleInput = RouterInputs["schedule"]["create"];

// Remove fields that the form does not edit
type ScheduleFormValues = Omit<CreateScheduleInput, "orgId">;

Adding a field to .input(z.object({...})) produces a type error in the form code that must now supply it.

5. Keep cache updates type-safe

The same inferred types flow into optimistic updates with TanStack Query.

utils.schedule.list.setData({ orgId }, (old) =>
  old?.map((s) => (s.id === id ? { ...s, done: true } : s)),
);
// old is inferred as RouterOutputs["schedule"]["list"] | undefined

The setData callback already has the correct argument type, so it needs no annotation. The fewer response types I write by hand, the more inference carries through the rest of the client.

Re-export the types from a monorepo package

When web and mobile use the same tRPC client types, a small package such as packages/api can re-export AppRouter, RouterInputs, and RouterOutputs.

// packages/api/src/index.ts
export type { AppRouter } from "../../apps/web/src/server/api/root";
export type { RouterInputs, RouterOutputs } from "../../apps/web/src/trpc/react";

My repository still has places where mobile imports AppRouter directly from the web app. The example above is the boundary I am moving toward. Because it still uses a relative path into the web implementation, moving the router definition itself into a shared package would make that boundary clearer later.

Summary

Derive UI types from RouterOutputs["router"]["procedure"] instead of rewriting them.
Use [number] for an array element and indexed access for nested values.
Derive form values from RouterInputs to avoid duplicating the Zod input schema.
Keep client type checks connected to server-side changes.

Environment

tRPC v11, TypeScript 5, Next.js 15, and Expo in a Turborepo monorepo

Turning Storybook stories into Vitest browser tests in Next.js

hiro@ — Thu, 03 Sep 2026 01:40:41 +0000

This article is an English translation of the original Japanese article.

Maintaining a UI component catalog and a separate component test suite costs too much in an indie Next.js project. I use a setup where writing a Storybook story also creates a browser test. The same artifact serves as both the catalog and the component test.

The setup combines Storybook's Vitest addon with Vitest browser mode. Most of it lives in two configuration files.

How it works

Storybook uses @storybook/nextjs-vite for the component catalog.
The @storybook/addon-vitest plugin turns each story into a test case.
Vitest browser mode runs the tests in real Chromium through Playwright rather than jsdom.

Adding Button.stories.tsx therefore adds a test that renders the button in a browser. If the story has a play function, the same test runs those interactions.

Configuration 1: `.storybook/main.ts`

import type { StorybookConfig } from '@storybook/nextjs-vite';

const config: StorybookConfig = {
  stories: ['../src/**/*.mdx', '../src/**/*.stories.@(js|jsx|mjs|ts|tsx)'],
  addons: [
    '@chromatic-com/storybook',
    '@storybook/addon-vitest',
    '@storybook/addon-a11y',
    '@storybook/addon-docs',
  ],
  framework: '@storybook/nextjs-vite',
  staticDirs: ['../public'],
};
export default config;

With @storybook/nextjs-vite, components that use Next.js-specific features such as next/image and next/navigation still run in the Vite-based Storybook. In my project it also starts noticeably faster than the webpack version.

Configuration 2: `vitest.config.ts`

Vitest projects separate regular unit tests from Storybook tests.

import { defineConfig } from 'vitest/config';
import { storybookTest } from '@storybook/addon-vitest/vitest-plugin';
import { playwright } from '@vitest/browser-playwright';

export default defineConfig({
  test: {
    projects: [
      // Regular unit tests for the logic layer
      {
        extends: true,
        test: {
          name: 'unit',
          include: ['src/**/*.test.ts'],
          environment: 'node',
        },
      },
      // Storybook tests: stories running in a browser
      {
        extends: true,
        plugins: [
          storybookTest({ configDir: path.join(dirname, '.storybook') }),
        ],
        test: {
          name: 'storybook',
          browser: {
            enabled: true,
            headless: true,
            provider: playwright({}),
            instances: [{ browser: 'chromium' }],
          },
        },
      },
    ],
  },
});

Two details matter here:

storybookTest() loads the story files and registers them as tests. A story needs no extra code for a render check. Add a play function when you want to verify interactions.
The Playwright provider runs the test in headless Chromium. CSS layout and focus behavior use a real browser implementation.

Because the projects are separate, I can run only the fast logic tests with vitest run --project unit, then use vitest run when I want the full suite including stories.

Why I keep this setup

The reason to write a test and the reason to write a catalog entry become the same. A separate component test suite is often the first thing I stop maintaining in a solo project. Here, the routine act of creating a story to inspect a component also adds a regression test.

Running in a real browser has also been more useful than I expected. Dialog focus traps, portals, and similar behavior can be missed or reported incorrectly by jsdom. Chromium exercises those paths directly.

The accessibility addon reports warnings in Storybook as well, so the catalog, component tests, and accessibility checks stay in one place.

Limitations

Browser mode is clearly slower than unit tests because it launches a browser. Splitting the projects lets me run only unit tests during most development work.
A story without a play function checks that rendering does not break. That is still useful, but important form components benefit from interaction tests.

Environment

Storybook 10 with @storybook/nextjs-vite and @storybook/addon-vitest
Vitest and @vitest/browser-playwright with Chromium
Next.js 15 App Router inside a Turborepo monorepo
The configuration is shortened from a project in production

I built a Qiita trend analyzer to decide what technical article to write next

hiro@ — Wed, 02 Sep 2026 01:36:17 +0000

This article is an English translation of the original Japanese article.

TL;DR

After returning to technical writing, I wanted data rather than intuition to guide topic selection.
I built a dependency-free tool of about 100 lines that uses only the Qiita API v2 to analyze tags and title patterns in recent high-rated articles.
Repository: https://github.com/takahiro-saeki/qiita-trend-analyzer
The results showed strong interest in practical AI articles, especially Claude Code, and list-style roundup titles.

Why I built it

I had not posted on Qiita for about four years when I decided to start writing technical articles again.

The first problem was choosing what to write. Looking back at my older posts, the best performer combined a current topic with working code and reached 34 LGTM. Articles based mostly on my own attachment to a topic did not perform as well. Topic selection clearly mattered.

Instead of relying only on instinct, I wanted to retrieve what people were currently reading and use that data when choosing a subject.

What the tool does

https://github.com/takahiro-saeki/qiita-trend-analyzer

# Analyze articles from the last seven days with at least five stocks
node analyze.mjs

# Change the date range and minimum stock count
node analyze.mjs --days 14 --min-stocks 10

It produces three reports:

Total LGTM by tag, showing which areas receive attention.
Frequency of title patterns such as "I tried", numbered lists, and introductions.
A list of articles with the most LGTM.

It uses the built-in fetch available in Node.js 18 and newer, with no package dependencies.

Implementation details

Qiita API v2 works without authentication

Article search queries can be sent without authentication. The unauthenticated limit is 60 requests per hour, while a token raises it to 1,000.

const query = `created:>=${since} stocks:>=${MIN_STOCKS}`;
const url = `https://qiita.com/api/v2/items?page=${page}&per_page=100&query=${encodeURIComponent(query)}`;
const res = await fetch(url, { headers });
const items = await res.json();

Combining created:>=date with stocks:>=count narrows the data to recent articles that have crossed a minimum engagement threshold. A few API calls are enough to build the sample.

Weight tags by total LGTM

Counting articles alone pushes high-volume tags to the top. I wanted to know how much engagement each tag's articles received, so the script sums likes_count for every tag.

const tagStats = new Map();
for (const it of items) {
  for (const t of it.tags) {
    const key = t.name.toLowerCase();
    const s = tagStats.get(key) ?? { name: t.name, count: 0, likes: 0 };
    s.count += 1;
    s.likes += it.likes_count;
    tagStats.set(key, s);
  }
}

Count title patterns with regular expressions

Popular articles often use recognizable title formats. The script uses simple regular expressions to count which ones are still common.

const patterns = [
  ["Tried it", /してみた/],
  ["Roundup or numbered list", /まとめ|\d+選/],
  ["Introduction or beginner", /入門|初心者/],
  // ...
];

The expressions analyze Japanese Qiita titles, so the labels above are English descriptions of the matched patterns.

Results from late July 2026

I analyzed 75 articles created in the previous seven days with at least five stocks.

#	Tag	Articles	Total LGTM
1	初心者 (beginner)	10	438
2	Security	6	404
3	AI	12	381
4	未経験エンジニア (new engineer)	6	372
5	新人プログラマ応援 (support for new programmers)	6	372
10	ClaudeCode	9	236

Several details stood out:

AI had both a high article count and a high total LGTM. Claude Code had nine articles and 236 LGTM, which was efficient per article.
The beginner and Security totals were heavily influenced by one roundup article about 138 sites for learning security, which received 330 LGTM. A successful roundup can dominate a tag.
High-ranked posts included practical operational material such as collections of CLAUDE.md design patterns.

At that point in summer 2026, concrete accounts of using AI tools in real development were receiving attention on Qiita. A surface-level library introduction still had to compete with many similar posts.

Trends are input, not a writing template

I use this analysis as a topic sensor, not as a reason to attach popular tags to thin articles. Qiita readers have become more critical of mass-produced articles that look AI-generated. Following a trend without original experience or verification can work against the author.

My current rule is to use data for choosing the subject, then fill the article with my own implementation, measurements, and mistakes.

Closing note

I built the tool with Claude Code in about an hour. I also plan to write about the workflow that connects topic selection, drafting, and publication.

The stack I use to run two indie web and iOS apps

hiro@ — Tue, 01 Sep 2026 02:13:54 +0000

This article is an English translation of the original Japanese article.

I develop and operate two services by myself, each with a web app and an iOS app. One manages community group activities, while the other records voice training.

The second project could reuse parts of the first. Authentication and deployment still need project-specific work, but fewer decisions start from zero. This article lists the current stack by layer, including the parts I have not fully cleaned up.

Overall structure

├── apps/
│   ├── web/      Next.js 15 (App Router) + React 19
│   └── mobile/   Expo SDK 54 (React Native 0.81)
└── packages/
    ├── api/            shared tRPC AppRouter type
    └── design-tokens/  color, spacing, and font constants

Monorepo: Turborepo and pnpm workspace
API: tRPC v11, with the router implementation in Next.js and only its types shared with mobile
Authentication: NextAuth v5 beta, with a JWT bridge for mobile
Database: Drizzle ORM and Cloudflare D1
Web UI: Tailwind CSS v4, a shadcn/ui-style component layer, and Base UI (@base-ui/react)
Mobile UI: React Native StyleSheet and shared design tokens
Tests: Vitest for unit tests and Storybook browser mode tests
Infrastructure: Cloudflare Workers through @opennextjs/cloudflare

API: remove duplicate types with tRPC v11

I do not run a separate API server. The Expo app calls the Next.js /api/trpc endpoint. packages/api is a small package that re-exports the router type. Some parts of the codebase still import AppRouter directly from the web app, so the package boundary is not completely settled, but the type-sharing direction is consistent.

The reason for choosing tRPC is simple. When one person writes both the web and mobile apps, maintaining API types in two places wastes time. I also considered REST with OpenAPI generation, but avoiding a generation step made tRPC a better fit for these projects.

Authentication: NextAuth v5 on web and JWT on mobile

The web app uses NextAuth cookie sessions with Google and Apple OAuth. Cookies are awkward on mobile, so the server issues a JWT after OAuth completes. Expo stores it in SecureStore and sends it in a Bearer header. The server context accepts either a cookie session or a Bearer token.

This was the part of the stack that took the most design work. Once the bridge was in place, the rest of the mobile API integration was much more direct.

Database: Drizzle and D1

The database is Cloudflare D1, which is SQLite-compatible, and the ORM is Drizzle. I like this combination for two reasons:

Drizzle relational queries make it easier to build SQL that fetches related records together.
drizzle-kit migrations fit D1's migration flow. I can apply the same SQL locally and in production.

D1 also has constraints. It does not expose interactive transactions, so multiple statements use batch(). Some PRAGMAs are unavailable as well. These differences matter if you approach it like a local SQLite connection, but they have not blocked the CRUD-heavy features in these apps.

UI: Tailwind and Base UI on web, shared tokens across platforms

The main web app has a shadcn/ui-style setup. Components live in my repository, cva manages variants, and Base UI provides the primitives. The other app uses a simpler setup centered on plain Tailwind. I adjust the UI layer to the size of each project.

The web and mobile apps share semantic names for colors, spacing, and fonts. Mobile imports the tokens directly into StyleSheet, while web repeats the same values as CSS variables. The web values are synchronized manually, so this is not a perfect single source of truth, but it removes many one-off color choices.

Tests: stories double as tests

Vitest handles logic-level unit tests. Storybook stories also run as browser mode tests in real Chromium. Writing a component catalog and writing a component test become the same task, which makes the test suite grow more naturally in a one-person project.

Infrastructure: mostly Cloudflare

Next.js deploys to Workers through @opennextjs/cloudflare.
D1 stores application data, and Workers serves static assets.
Production and development use separate deployments and separate D1 databases.

I chose this setup for cost and low operational overhead. Current usage fits within the free tiers for Workers and D1, and I do not manage a server.

Deployment is one command chain:

opennextjs-cloudflare build && wrangler deploy

The mobile app follows the standard Expo build and App Store submission flow.

Weak points in the stack

NextAuth v5 is still beta, so I accept the risk of breaking changes.
D1 has less community material than older databases. When search results are thin, I read the official documentation and source.
Mobile store review cannot be removed by a stack choice. Web changes deploy immediately, while app releases require review, so the API needs backward compatibility.

Reuse matters more on the second project

I did not evaluate this stack only by how fast it built the first project. I cared about how much could carry into the second one. The monorepo structure, authentication bridge, design tokens, and deployment procedure all became reusable starting points. That let the second project begin with its product-specific features instead of another round of infrastructure selection.

I have separate articles that go deeper into tRPC type sharing, D1 migration, and Base UI.

Environment

Turborepo, pnpm, Next.js 15, React 19, Expo SDK 54, and React Native 0.81
tRPC v11, TanStack Query v5, superjson, NextAuth v5 beta, and jose
Drizzle ORM 0.41, Cloudflare D1, Tailwind CSS v4, @base-ui/react, and cva
Vitest, Storybook with nextjs-vite, Playwright, @opennextjs/cloudflare, and Wrangler

Three problems I hit deploying Next.js 16 to Cloudflare Workers with OpenNext

hiro@ — Mon, 31 Aug 2026 01:51:15 +0000

This article is an English translation of the original Japanese article.

I deployed a Next.js application with App Router, API routes, and D1 to Cloudflare Workers through @opennextjs/cloudflare. The basic process followed the official documentation, but I ran into three problems that were not covered there. This article records the errors and the fixes.

The basic deployment flow looks like this:

npm i @opennextjs/cloudflare@latest
npm i -D wrangler@latest
# Add wrangler.jsonc and open-next.config.ts
npx opennextjs-cloudflare build
npx opennextjs-cloudflare deploy

Problem 1: Next.js 16.2.10 fails the peer dependency check

Installing @opennextjs/cloudflare immediately failed with a peer dependency error.

npm error Could not resolve dependency:
npm error peer next@">=15.5.21 <16 || >=16.2.11" from @opennextjs/cloudflare@1.20.2

The project used Next.js 16.2.10, while the adapter required 16.2.11 or newer for the 16.x line. The project missed the accepted range by one patch version.

The fix was a Next.js patch update.

npm i next@16.2 eslint-config-next@16.2

--legacy-peer-deps could force the installation, but I saw no reason to keep a version that the adapter explicitly excludes.

Problem 2: generated Wrangler types collide with DOM types

I ran wrangler types to add types for the D1 binding. TypeScript errors then appeared throughout the application.

error TS18046: 'body' is of type 'unknown'.
error TS2339: Property 'name' does not exist on type 'object'.

The generated worker-configuration.d.ts includes global Workers runtime types such as Request, Response, and Body. Those names overlap with the DOM types expected by Next.js. Once both sets of globals entered the same project, request.json() returned unknown instead of the DOM definition's type.

I cover the details in a separate article. The short version is to stop generating the full runtime definitions and write a small declaration file that imports only the required binding types.

// cloudflare-env.d.ts, written manually
import type { D1Database, Fetcher } from "@cloudflare/workers-types";

declare global {
  interface CloudflareEnv {
    DB: D1Database;
    ASSETS: Fetcher;
  }
}

export {};

Problem 3: a temporary 404 with error code 1042 after deployment

The deploy command succeeded and printed the URL, but the first curl request returned a 404. The response body contained only this Cloudflare error:

error code: 1042

Error 1042 normally means that a Worker tried to make a subrequest to its own hostname. For a moment, I suspected that OpenNext asset loading was broken.

In this deployment, all routes returned 200 after a short wait and the error did not return. I also observed a period where a HEAD request returned 200 while GET returned 404. Error 1042 is still a real subrequest error, so a persistent failure requires checking Worker routes and request targets.

If it happens only immediately after deployment, retrying after one or two minutes is worth doing. If it continues, do not assume propagation is the cause.

Additional notes

wrangler.jsonc needs the nodejs_compat compatibility flag for OpenNext.
For local testing, building first and then running wrangler dev reproduced the Workers runtime more directly than opennextjs-cloudflare preview in my setup.
With D1, adding initOpenNextCloudflareForDev() to next.config.ts lets next dev use local D1 and keeps development and production code paths closer.

Summary

Problem	Symptom	Fix
Peer dependency	Next.js 16.2.10 is excluded	Update to Next.js 16.2.11 or newer
`wrangler types`	`json()` becomes `unknown`	Use a handwritten declaration file with `import type`
Error 1042	Temporary 404 after deployment	Retry, then inspect routing if it persists

Each problem has a small fix once identified, but the first error message does not always point to the correct layer.

Environment

Next.js 16.2, @opennextjs/cloudflare 1.20, and Wrangler 4.113
Cloudflare Workers and D1

Adding Expo authentication to a NextAuth-based web service

hiro@ — Sun, 30 Aug 2026 01:55:49 +0000

This article is an English translation of the original Japanese article.

I added an Expo app to an existing Next.js web service that already used NextAuth, now Auth.js, for authentication. NextAuth assumes a cookie-based session, which does not fit a mobile app particularly well.

Replacing the authentication platform was one option. Instead, I kept NextAuth on the web and added a JWT issuing endpoint for mobile. This article records the structure I use in a live service and the problems that remain. It is not a finished authentication blueprint.

Overall flow

There are three parts:

Web, built with Next.js: NextAuth with Google and Apple OAuth, using a cookie session
Mobile, built with Expo: a Bearer JWT rather than cookies
Bridge: run the web OAuth flow in an in-app browser and return a JWT to the app when it completes

Mobile app                Web (Next.js)
  │ openAuthSessionAsync     │
  ├────────────────────────→ │ /api/auth/mobile-callback?action=login&redirect=exp://...
  │                          │   → NextAuth sign-in → Google OAuth
  │                          │   → OAuth completes and cookie session is created
  │                          │   → issue JWT
  │ ←──────────────────────  │   → redirect to exp://...?token=xxx
  │ save token in SecureStore│
  │                          │
  │ Later API calls: Authorization: Bearer xxx

Mobile: use `openAuthSessionAsync` as the bridge

The Expo login button only needs to open the web login flow with expo-web-browser.

import * as WebBrowser from "expo-web-browser";

const redirectUrl = Linking.createURL("/login"); // exp:// or squadnote://
const loginUrl = `${config.apiUrl}/api/auth/mobile-callback?action=login&redirect=${encodeURIComponent(redirectUrl)}`;

const result = await WebBrowser.openAuthSessionAsync(loginUrl, redirectUrl);
// result.url contains exp://...?token=xxx

openAuthSessionAsync opens a browser session for authentication and returns to the app when a redirect to the requested scheme occurs. That makes it a practical bridge for the OAuth flow.

I store the returned token with expo-secure-store.

import * as SecureStore from "expo-secure-store";

export async function setToken(token: string): Promise<void> {
  await SecureStore.setItemAsync("squadnote_jwt", token);
}

Server: let `mobile-callback` issue the JWT

I added a mobile-specific callback Route Handler to the web app. It does three things:

On ?action=login, save the mobile redirect target in a cookie and continue to NextAuth sign-in.
After OAuth returns, call auth() to identify the user from the new cookie session.
Issue a JWT and redirect to the mobile scheme with ?token=xxx.

// /api/auth/mobile-callback, shortened
export async function GET(request: Request) {
  const session = await auth(); // Cookie session exists after OAuth
  if (!session?.user?.id) { /* continue to sign-in */ }

  const token = await signJwt(session.user.id, secret); // signed with jose
  return NextResponse.redirect(`${mobileRedirect}?token=${token}`);
}

Redirect validation and its limitations

If the redirect parameter accepts any URL, the server could send the JWT somewhere unintended. My current implementation limits redirects to schemes used by the app.

// Allow Expo development schemes or the production custom scheme
function isAllowedMobileRedirect(redirect: string): boolean {
  return (
    redirect.startsWith("exp://") ||
    redirect.startsWith("exps://") ||
    redirect.startsWith("squadnote://")
  );
}

I do not consider this prefix check sufficient. Parsing the URL and validating the host and path as well as the scheme would be safer. The development exp:// allowance is broad, so production should accept only a fixed callback under the custom scheme.

The other problem is placing the JWT itself in the redirect URL. Expo AuthSession can receive an authorization code instead. I plan to return a short-lived code to the app and exchange it for a JWT on the server. I would not use the current code unchanged as an authentication template.

Let the API accept cookies and Bearer tokens

The tRPC or API context first checks the cookie session. If no session exists, it falls back to a Bearer token.

// tRPC context, shortened
// Web: cookie session / Mobile: Authorization: Bearer <JWT>
const session = await auth();
if (!session) {
  const authHeader = opts.headers.get("authorization");
  if (authHeader?.startsWith("Bearer ")) {
    const payload = await verifyJwt(authHeader.slice(7), secret);
    // Build a session-like value from the user ID in payload
  }
}

Web and mobile can then call the same procedures. The mobile tRPC client adds the token in its headers() callback for every request. The authentication paths differ, but authorization stays shared at the procedure layer.

Two operational pieces worth adding early

The first is automatic logout on 401. Tokens eventually expire. Wrapping fetch so it deletes the token and returns to the login screen avoids adding the same error handling to every screen.

const authAwareFetch: typeof fetch = async (input, init) => {
  const response = await fetch(input, init);
  if (response.status === 401) void handleUnauthorized();
  return response;
};

Apple sign-in uses a separate native path through expo-apple-authentication. The app posts the native credential to the server, which verifies it and returns the same JWT format. Token storage and subsequent API calls are shared with the browser-based path.

Tradeoffs in the current design

JWT revocation relies only on expiration. Immediate remote logout would require storing token state in the database or adding a version number.
I left NextAuth's session strategy and callbacks alone, so the web authentication path did not need to change. Preserving the working web login was the main constraint.

This structure let me add the app without replacing the existing web authentication. The JWT in the redirect URL and the redirect validation still need work. I found it useful to separate the structure needed to get the app running from the security work required before treating it as a reusable design.

Environment

Expo SDK 54 with expo-web-browser, expo-secure-store, and expo-apple-authentication
Next.js 15, NextAuth v5 beta, jose, and tRPC v11
The code is shortened from a service in production

Cloudflare D1 has no BEGIN TRANSACTION, so I tested its limits and batch API

hiro@ — Sat, 29 Aug 2026 04:27:23 +0000

This article is an English translation of the original Japanese article.

Cloudflare D1 is commonly described as SQLite-compatible, and most SQL works as expected. After migrating from local SQLite, however, I found several places where treating D1 like a normal SQLite connection fails.

The biggest difference is that D1 does not expose explicit transactions. I ran the commands myself to see the exact errors and then adjusted the application design around batch().

Test 1: `BEGIN TRANSACTION` is rejected

$ wrangler d1 execute my-db --local --command "BEGIN TRANSACTION"

D1 runs your SQL in a transaction for you.
Please export an SQL file from your SQLite database and try again.

The error is direct. D1 wraps an individual query, or a batch, in a transaction automatically. It does not let application code keep a connection open and choose an arbitrary BEGIN and COMMIT boundary.

Long interactive transactions are also a poor match for a serverless database connection model, so this limitation is part of the design rather than a missing SQLite command.

Test 2: most PRAGMAs are restricted

I also tried applying a setting from the local SQLite setup.

$ wrangler d1 execute my-db --local --command "PRAGMA journal_mode = WAL"

✘ [ERROR] not authorized: SQLITE_AUTH

Low-level settings such as journal mode belong to D1's managed environment. They cannot be changed by the application. During migration, remove those PRAGMA statements from the schema. Foreign key enforcement is enabled by default, so PRAGMA foreign_keys = ON is not needed either.

Use `batch()` for atomic groups of statements

A common requirement is to insert one record, update another, and roll everything back if either statement fails. D1 handles that with batch().

// Raw D1 API
const results = await env.DB.batch([
  env.DB.prepare("INSERT INTO orders (id, user_id) VALUES (?, ?)").bind(orderId, userId),
  env.DB.prepare("UPDATE inventory SET stock = stock - 1 WHERE item_id = ?").bind(itemId),
]);

D1 runs the statements in a batch as one transaction and rolls back the entire batch when a statement fails. It also sends the statements in one round trip, which matters because each D1 query adds network latency.

Drizzle ORM exposes the same model through db.batch([...]).

await db.batch([
  db.insert(orders).values({ id: orderId, userId }),
  db.update(inventory).set({ stock: sql`${inventory.stock} - 1` }).where(eq(inventory.itemId, itemId)),
]);

Read-then-write logic is the real design boundary

A batch works when the complete list of statements is known before execution. A typical interactive SQLite transaction may instead do this:

Read the current value with SELECT.
Make a decision in application code.
Run a different UPDATE based on that result.

There is no place for application-side branching inside a D1 batch. I usually handle that in one of these ways:

Fold the condition into one statement. For example, run UPDATE inventory SET stock = stock - 1 WHERE item_id = ? AND stock > 0, then inspect whether meta.changes is zero.
Use optimistic locking. Include the version read earlier in the UPDATE condition and retry if no row changes.
Move the part that needs strict serialized access to Durable Objects. A single-entity coordination problem can be a better fit for DO storage than D1.

For the CRUD applications I migrated, moving the condition into one statement covered nearly every case. I did not end up with a feature that required an interactive transaction.

SQLite habits and their D1 equivalents

SQLite habit	D1 behavior
`BEGIN` ... `COMMIT`	Unavailable. D1 uses automatic transactions.
`PRAGMA journal_mode` and similar settings	Unavailable with `SQLITE_AUTH`. D1 manages them.
Atomic execution of multiple statements	Use `batch()` for one transaction and one round trip.
Read, decide, then write	Fold into `WHERE`, use optimistic locking, or use Durable Objects when needed.

"SQLite-compatible" describes the SQL dialect, not an identical transaction model. Knowing that distinction before migration prevents designing around a connection model D1 does not provide.

Environment

Cloudflare D1 and Wrangler 4.113, tested with --local; remote D1 has the same restriction
Drizzle ORM 0.41 batch API

Keeping colors consistent between Tailwind on the web and React Native

hiro@ — Fri, 28 Aug 2026 07:15:56 +0000

This article is an English translation of the original Japanese article.

I maintain an indie service with both a Next.js web app and an Expo iOS app. Design consistency does not happen by itself because the web app uses Tailwind utilities while React Native uses StyleSheet.

I added a small packages/design-tokens package to the monorepo so both apps use the same names for colors, typography, spacing, and border radii. React Native imports the package directly. The web app defines the same values as CSS variables. It is not a fully generated single source of truth, but it has been enough to reduce color drift in a small project.

Project structure

├── apps/
│   ├── web/      ← Next.js + Tailwind CSS v4
│   └── mobile/   ← Expo (React Native StyleSheet)
└── packages/
    └── design-tokens/
        └── src/
            ├── colors.ts      ← semantic colors
            ├── typography.ts  ← font sizes and weights
            ├── spacing.ts     ← spacing and layout
            └── radius.ts      ← border radii

The tokens are plain TypeScript constants. I did not add a build tool or a transformation layer such as Style Dictionary.

// packages/design-tokens/src/colors.ts
export const colors = {
  /** Main color for buttons, links, and active states */
  primary: "#0891b2",
  primaryForeground: "#ffffff",

  /** Page background */
  background: "#f9fafb",
  foreground: "#111827",

  /** Cards and panels */
  card: "#ffffff",
  cardForeground: "#111827",

  /** Destructive actions */
  destructive: "#ef4444",
  destructiveForeground: "#ffffff",
  // ...
} as const;

The important part is using semantic names such as primary and destructive. Calling a token "main color" rather than "cyan 500" lets its consumers think about meaning instead of a particular shade. Changing a web color still requires synchronizing the CSS variables described below.

React Native: import the tokens directly

The mobile side is straightforward because StyleSheet can use the TypeScript constants directly.

// apps/mobile/src/app/login.tsx
import { colors, textColors } from "@squadnote/design-tokens";

const styles = StyleSheet.create({
  container: {
    backgroundColor: colors.background,
  },
  title: {
    color: textColors.primary,
  },
  button: {
    backgroundColor: colors.primary,
  },
});

The as const assertion preserves literal types, so the editor can suggest every available token. On the React Native side, the lack of extra machinery is one of the best parts of this setup.

Tailwind v4: define the same values as CSS variables

The web side needs one extra layer because Tailwind classes cannot read JavaScript constants. CSS variables provide the meeting point.

/* apps/web/src/styles/globals.css */
:root {
  /* Light theme: same HEX values as @squadnote/design-tokens */
  --background: #f9fafb;
  --foreground: #111827;
  --card: #ffffff;
  --primary: #0891b2;
  --primary-foreground: #ffffff;
  /* ... */
}

Tailwind v4 can map CSS variables to utilities through @theme. Classes such as bg-primary and text-foreground then use the same HEX values as the mobile app.

I synchronize this part manually. A comment next to the CSS variables says that they match design-tokens, and I update both places when a color changes. I could generate CSS from TypeScript, but color changes are infrequent enough that another build step would cost more than it saves. If the token set grows much larger, I will probably switch to generation.

The main benefit is removing color selection from routine work

Since adding the package, I make fewer one-off color decisions on new screens. Instead of deciding which color a border should use, I start with colors.border.

The same semantic names can also be used for Figma variables. That removes some ambiguity when moving from a mockup to implementation, especially when the same person handles both design and code.

When this setup fits

This works well for a small team building both web and React Native apps without enough tokens to justify a dedicated transformation pipeline. The tradeoff is that the web values still require manual synchronization.

For extensive theme switching, including dark mode, or two-way synchronization with design tools, I would start with a system such as Style Dictionary or Tokens Studio. Manually duplicated CSS variables become difficult to maintain as the number of themes grows.

Environment

Turborepo and pnpm workspace
Web: Next.js 15 and Tailwind CSS v4
Mobile: Expo SDK 54 and React Native 0.81
The code samples are shortened extracts from a service in production

Protecting a personal web app with Cloudflare Access and email OTP

hiro@ — Thu, 27 Aug 2026 05:17:44 +0000

This article is an English translation of the original Japanese article.

I deployed a personal task management app to Cloudflare Workers, but I did not want anyone with the URL to be able to open it. Building and maintaining a login system for an app with one user felt excessive.

Cloudflare Access fit this use case. It can place email one-time-code authentication in front of a workers.dev URL without any application code changes, and the setup is available on the free plan.

Why I chose Access instead of an application login

My decision came down to three points:

For an app with static assets and APIs, adding a login screen does not stop someone from downloading the JavaScript bundle directly. Any data included in the bundle remains visible.
Access authenticates the request at the edge before it reaches the application. HTML, JavaScript, and API routes receive the same protection.
There is no login implementation or password store to maintain. The user receives a code by email.

Putting authentication in front of the application usually requires infrastructure work. Since this app already runs on Cloudflare, it was a dashboard setting.

Setup

1. Enable Access on the `workers.dev` URL

In the Cloudflare dashboard, open Workers & Pages, select the Worker, and open Domains & Routes. The workers.dev URL has a visibility dropdown. Choose the option to protect it with Access.

Cloudflare then confirms that visitors must sign in and match an Access policy before the Worker loads. Once enabled, Access handles the request before the Worker.

2. Allow only your email address

Open the Cloudflare Access management screen and restrict the policy to your own email address. Opening the URL now follows this flow:

Access redirects to its sign-in page.
Entering the email address sends a six-digit one-time code.
Entering the code opens the application.

The same flow works from a phone.

3. Close the preview URL too

The same dashboard also includes the preview URL, which looks like *-project-name.subdomain.workers.dev. Protecting the main URL while leaving the preview public can expose the latest deployment through that route. Disable the preview URL if you do not use it, or protect it with Access as well.

4. Complete Zero Trust setup if needed

The first visit to the Access management screen may ask you to select a plan. The Free plan covers up to 50 users at no charge. Cloudflare may ask for a payment method during setup, but the Free plan itself does not create a charge.

You can also change the session duration under Access, Applications, and the selected application. For a personal app, extending it up to one month avoids entering a code every day.

Verify that Access is active

Opening the app in a private browser window should show the Access login page. You can also check with curl.

$ curl -s -o /dev/null -w "%{http_code}\n" https://my-app.example.workers.dev/
302

An unauthenticated request should receive a 302 redirect to *.cloudflareaccess.com instead of reaching the application. Check an /api/... route as well to confirm that the protection applies to both pages and APIs.

About the Access JWT warning

When enabling Access, the dashboard warns that Workers handling sensitive data should validate the Access JWT and reject requests that bypass Access.

This protects against future routes that do not pass through the configured Access application. My current setup exposes only the protected workers.dev URL. Adding a custom domain or another route would change that assumption. For sensitive data, validating the Access JWT inside the Worker adds another boundary instead of relying only on the entry route configuration. The AUD tag and JWK public key URL used for validation are not secrets like passwords or API keys.

What this setup provides

Access restricts a personal app without adding application login code.
A workers.dev URL can be protected directly from the dashboard without a custom domain.
Preview URLs need their own protection or should be disabled.
A longer session duration keeps the app convenient for daily personal use.

Environment

Cloudflare Workers on a workers.dev domain and Cloudflare Access on the Zero Trust Free plan
The application uses Next.js and @opennextjs/cloudflare, but the Access setup does not depend on the application framework

Using Base UI with a shadcn/ui-style component layer in production

hiro@ — Wed, 26 Aug 2026 00:30:33 +0000

This article is an English translation of the original Japanese article.

I use Base UI (@base-ui/react) for the UI primitives in an indie web service. Base UI is an unstyled React component library.

I like the shadcn/ui approach of combining Tailwind, cva, and components that live in my own repository, but I wanted Base UI underneath that component layer. This article shows the structure I use and the differences I noticed after working with Radix-based components.

Overall structure

Following the same idea as shadcn/ui, I keep thin wrappers that I own under components/ui/. The only major change is that the primitives come from Base UI instead of Radix.

components/ui/
├── button.tsx        ← @base-ui/react/button
├── dialog.tsx        ← @base-ui/react/dialog
├── tabs.tsx          ← @base-ui/react/tabs
├── sheet.tsx         ← built on dialog
├── avatar.tsx        ← @base-ui/react/avatar
├── dropdown-menu.tsx
├── select.tsx
└── ...

Here is a shortened version of the button wrapper. It defines variants with cva and applies them to the Base UI primitive, which should look familiar if you have used shadcn/ui.

"use client"

import { Button as ButtonPrimitive } from "@base-ui/react/button"
import { cva, type VariantProps } from "class-variance-authority"

const buttonVariants = cva(
  "inline-flex items-center justify-center rounded-lg text-sm font-medium transition-all focus-visible:ring-3 focus-visible:ring-ring/50 active:scale-[0.98] disabled:opacity-50 ...",
  {
    variants: {
      variant: {
        default: "border-primary bg-primary text-primary-foreground ...",
        outline: "border-border bg-background hover:bg-muted ...",
        destructive: "bg-destructive/10 text-destructive ...",
      },
      size: { default: "h-8 px-2.5", sm: "h-7 px-2.5", icon: "size-8" },
    },
  },
)

Differences you notice when coming from Radix

1. Imports use component subpaths

import { Dialog as DialogPrimitive } from "@base-ui/react/dialog"
import { Button as ButtonPrimitive } from "@base-ui/react/button"

Instead of packages such as @radix-ui/react-dialog, Base UI uses one package with subpath imports. This has made dependency management simpler for me.

2. Types are organized into namespaces

Base UI exposes types through namespaces such as DialogPrimitive.Root.Props.

function DialogContent({
  className,
  children,
  ...props
}: DialogPrimitive.Popup.Props & { showCloseButton?: boolean }) {
  // ...
}

For wrappers, this is more direct than writing React.ComponentProps<typeof DialogPrimitive.Content> and keeps the type declarations shorter.

3. Some parts have different names

Radix calls the dialog overlay Overlay, while Base UI calls it Backdrop. The dialog body is Popup rather than Content. When porting a shadcn/ui dialog to Base UI, this is the mapping to remember.

<DialogPortal>
  <DialogPrimitive.Backdrop className="fixed inset-0 bg-black/10 ..." />
  <DialogPrimitive.Popup className="fixed top-1/2 left-1/2 z-50 ...">
    {children}
  </DialogPrimitive.Popup>
</DialogPortal>

4. State attributes are `data-open` and `data-closed`

Radix uses a single attribute such as data-state="open". Base UI adds attributes for each state, including data-open and data-closed. The Tailwind classes change accordingly.

Radix:   data-[state=open]:animate-in  data-[state=closed]:animate-out
Base UI: data-open:animate-in          data-closed:animate-out

It is a small difference, but the class strings become noticeably shorter. That helps when a shadcn-style component layer contains many animated components.

What it has been like to use

Dialog, Popover, and Tooltip have structures that feel close to their Radix counterparts. The part names, data attributes, and type references still need to be translated.
Radix still has more documentation and accumulated community knowledge. Searching an error rarely finds an article about Base UI, so I expect to read the official documentation and GitHub issues.
Most shadcn/ui structure and class design can be reused. Replacing the primitives and mapping the names account for most of the work.

If Radix already works for your project, there is no need to replace it in a hurry. I tried Base UI in a new project and adopted it while checking the differences in each component I needed.

Environment

@base-ui/react 1.3, Next.js 15 App Router, Tailwind CSS v4, and class-variance-authority
The code samples are shortened extracts from a service in production

API Design That Allows Partial Failures and Saves Only Successful Assets

hiro@ — Tue, 25 Aug 2026 00:29:20 +0000

This article is an English translation of the original Japanese article.

When generating, saving, and updating multiple assets to adopted state, treating one failure as total failure makes re-execution difficult. It also creates a mismatch where the external API has images but local history does not.

In Pixel Studio, I finalize results per item and include both success count and failure details in the response.

Don't wrap everything in try/catch

Process each item individually instead of the entire batch.

const successes = [];
const failures = [];

for (const input of inputs) {
  try {
    const result = await generate(input);
    await saveHistory(result);
    successes.push(result);
  } catch (error) {
    failures.push({
      sourceKey: input.sourceKey,
      error: error instanceof Error ? error.message : String(error),
    });
  }
}

If generation succeeds, save the history immediately. Saving everything after the loop means a late exception loses earlier results.

Return stable identifiers

Failure results include sourceKey instead of array index.

{
  "succeeded": 3,
  "failures": [
    {
      "sourceKey": "history:image-42",
      "error": "rate limited"
    }
  ]
}

The UI can identify which asset failed even after sorting or re-fetching. Retries can target individual sourceKey values.

Separate saved from adopted

Saving an image file is different from deciding to adopt it for the game. Assets have states like review, adopted, rejected and an assetPath.

Saved generation results start as review candidates. After human confirmation and adoption, they reconcile with the game manifest. Without this distinction, download success would be treated as adoption.

Only treat zero successes as request failure

Return results if at least one item succeeded. Return an error response only when all items failed. The client can add successes to the list and notify about failures.

Adopting partial success requires making the process closer to idempotent. Decide upfront how to handle re-saving the same sourceKey, whether to reuse external job IDs, and whether to allow duplicate file names.

Returning batch completion as only true or false makes the retry unit the entire batch. Finalizing successful items immediately and returning failures in an identifiable form lets you narrow the retry scope even when processing involves external APIs.

DEV Community: hiro@

When Wrangler-generated types collide with Next.js DOM types

What happened

Attempt: --include-runtime=false

Fix: a handwritten declaration file with import type

Tradeoff

Summary

Environment

Removing handwritten API types with tRPC RouterInputs and RouterOutputs

1. Get the item type from a list

2. Use the output type for child component props

3. Index into nested properties

4. Build form values from RouterInputs

5. Keep cache updates type-safe

Re-export the types from a monorepo package

Summary

Environment

Turning Storybook stories into Vitest browser tests in Next.js

How it works

Configuration 1: .storybook/main.ts

Configuration 2: vitest.config.ts

Why I keep this setup

Limitations

Environment

I built a Qiita trend analyzer to decide what technical article to write next

TL;DR

Why I built it

What the tool does

Implementation details

Qiita API v2 works without authentication

Weight tags by total LGTM

Count title patterns with regular expressions

Results from late July 2026

Trends are input, not a writing template

Closing note

The stack I use to run two indie web and iOS apps

Overall structure

API: remove duplicate types with tRPC v11

Authentication: NextAuth v5 on web and JWT on mobile

Database: Drizzle and D1

UI: Tailwind and Base UI on web, shared tokens across platforms

Tests: stories double as tests

Infrastructure: mostly Cloudflare

Weak points in the stack

Reuse matters more on the second project

Environment

Three problems I hit deploying Next.js 16 to Cloudflare Workers with OpenNext

Problem 1: Next.js 16.2.10 fails the peer dependency check

Problem 2: generated Wrangler types collide with DOM types

Problem 3: a temporary 404 with error code 1042 after deployment

Additional notes

Summary

Environment

Adding Expo authentication to a NextAuth-based web service

Overall flow

Mobile: use openAuthSessionAsync as the bridge

Server: let mobile-callback issue the JWT

Redirect validation and its limitations

Let the API accept cookies and Bearer tokens

Two operational pieces worth adding early

Tradeoffs in the current design

Environment

Cloudflare D1 has no BEGIN TRANSACTION, so I tested its limits and batch API

Test 1: BEGIN TRANSACTION is rejected

Test 2: most PRAGMAs are restricted

Use batch() for atomic groups of statements

Read-then-write logic is the real design boundary

SQLite habits and their D1 equivalents

Environment

Keeping colors consistent between Tailwind on the web and React Native

Project structure

React Native: import the tokens directly

Tailwind v4: define the same values as CSS variables

The main benefit is removing color selection from routine work

When this setup fits

Environment

Protecting a personal web app with Cloudflare Access and email OTP

Why I chose Access instead of an application login

Setup

1. Enable Access on the workers.dev URL

Attempt: `--include-runtime=false`

Fix: a handwritten declaration file with `import type`

4. Build form values from `RouterInputs`

Configuration 1: `.storybook/main.ts`

Configuration 2: `vitest.config.ts`

Mobile: use `openAuthSessionAsync` as the bridge

Server: let `mobile-callback` issue the JWT

Test 1: `BEGIN TRANSACTION` is rejected

Use `batch()` for atomic groups of statements

1. Enable Access on the `workers.dev` URL

4. State attributes are `data-open` and `data-closed`