DEV Community: sp0033212000

Generating API Types When Frontend and Backend Both Live on Feature Branches

sp0033212000 — Mon, 19 Oct 2026 16:08:03 +0000

Our frontend API types are generated from the backend's OpenAPI (Swagger) spec with swagger-typescript-api. With one project, that was a ten-line script: fetch the spec, write the file, done. Then we had more frontend projects, each with its own copy of that script, each a little different. Nobody could tell which copy had which fix.

Branches were the real headache, though. When the backend builds a feature, it works on a feature branch, and the frontend needs types from that branch, not from dev. That raises two questions:

How does the frontend know which branch's spec to fetch?
What about the gap between the feature branch and dev?

The second one is sneakier. Once a backend feature branch is cut, it usually isn't rebased onto dev very often. Meanwhile other features land in dev along with their APIs, and none of those exist in your feature branch's spec. The frontend, on the other hand, rebases onto dev all the time. The moment you do, you pull in code from other features that already calls those new APIs. Now your code uses endpoints that the spec you're generating types from has never heard of, and typecheck fails. You didn't break anything, but CI is red.

backend  dev           ──o──────────●──────────────   ● other branch merges API X
backend  ft-coupon-v2     └──o──────────o──────────   no rebase: spec has no API X

frontend dev           ──o──────────────●──────────   ● code that calls API X
frontend ft-coupon-v2     └──o─────────────●───────   rebased onto dev: now calls API X
                                           │
                types generated from backend ft-coupon-v2 spec
                → API X missing → typecheck fails

So I built an internal CLI package that owns the whole "which spec, how to merge it, where to write it" job. Nine frontend projects use it today, and several teammates have added features and fixed bugs in it since. This post walks through how it works and the traps we hit merging two OpenAPI specs. That second part applies no matter what generator you use.

The core idea: same-named branches

The answer to question one is a naming rule: the frontend branch uses the same name as the backend branch. If the backend opens ft-coupon-v2, so does the frontend.

That means there's nothing to configure. The branch you're on already tells the tool which spec you want. Switch branches and your types follow. CI runs the same logic. It also makes conversations easier: when someone says ft-coupon-v2, frontend and backend mean the same feature.

A naming rule alone isn't enough, though. The frontend also needs to know whether the backend actually has a spec for that branch. So I asked the backend team for one more endpoint: a list of branches that currently have a deployed spec. Before generating, the tool calls it and looks for its own branch name:

Found: fetch that branch's spec and merge it with dev's (more on the merge below).
Not found: this branch only exists on the frontend side, so fall back to the staging spec.

current branch ──> branch-list endpoint ──> same name exists?
                                              │ yes ──> merge dev + branch spec ──┐
                                              │ no  ──> use staging spec ─────────┴──> generate types

Nobody has to remember to point a config at the right branch anymore. Without this, it's easy to forget to switch it back and build production with feature-branch types, or to keep fetching a spec for a backend branch that was merged and deleted last week. Now the lookup decides.

The same mapping applies at runtime. Every backend feature branch is deployed to its own endpoint, so by default the frontend calls the endpoint matching its branch, and the types and the backend you're talking to come from the same source. If you want a different backend (say you're on a feature branch but want to test against staging data), you set an environment variable. If it's set, it wins. If not, the tool silently uses the feature branch's endpoint. Day to day, you set nothing.

The basics: one config file, one command

Each project has one config file at its root listing which docs to generate and where:

import { genConfig, API_DOC_NAME } from '@team/fe-manifest';

export default genConfig({
  outputDir: 'src/swagger',
  docs: [
    { doc: API_DOC_NAME.Public_API, outputFileName: 'public.api.ts' },
    { doc: API_DOC_NAME.Member_API, outputFileName: 'member.api.ts' },
  ],
});

Then npx hc-manifest generates the typed clients. The genConfig wrapper is there so the config file itself is type-checked: misspell a doc name and your editor tells you.

To get the current branch name, the tool checks, in order:

A --branch flag
The current git branch
CI environment variables: GITHUB_HEAD_REF, GITHUB_REF_NAME, EAS Build's EAS_BUILD_GIT_COMMIT_BRANCH, and so on, first one with a value wins

One gotcha: CI often checks out a commit SHA, and then git rev-parse --abbrev-ref HEAD just returns HEAD. Treat that as "no answer" and keep going to the environment variables, or you'll end up looking for a branch literally named HEAD.

Once it has a name, it checks it against the backend's branch list and falls back to staging if there's no match. The generated file's header also records which branch it came from and when the spec was last updated. If neither has changed on the next run, generation is skipped.

Merging two specs: don't just deep merge

Back to question two. On a feature branch (ours start with ft-), the tool fetches both the dev spec and the feature branch spec, uses dev as the base, and lays the feature branch on top. New or changed APIs from the feature branch win, and everything other people added to dev stays.

My first version used lodash.merge. Seems reasonable, until you remember how it handles arrays: index by index. OpenAPI is full of arrays, and that produced two quiet bugs. Credit where it's due: teammates caught and fixed both of these in real projects.

Bug 1: parameters merged into each other. Say an operation in dev has four parameters and the fourth is a header. The feature branch puts a new boolean query parameter in that same slot. Merge by index and those two unrelated parameters get blended into one. The boolean param came out typed as string.

The fix is to merge parameters by identity (name + in), not position:

const mergeParamsByIdentity = (devParams: Param[], ftParams: Param[]) => {
  const key = (p: Param) => `${p.name}::${p.in}`;
  const ftKeys = new Set(ftParams.map(key));
  // feature branch params win; dev-only params are appended
  return [...ftParams, ...devParams.filter((p) => !ftKeys.has(key(p)))];
};

Bug 2: an enum lost a value. An enum in dev had nine values. The feature branch was cut earlier and was missing one in the middle, so it had eight. Merged by index, everything after the gap shifted up by one and the last value showed up twice. The generated enum was quietly one value short, the frontend's typecheck broke, and nothing warned us. With a different ordering you can even get a combination that neither branch ever declared. required arrays have the same problem.

The fix is lodash.mergeWith with a customizer that decides how arrays merge:

const mergeArrayCustomizer = (devValue: unknown, ftValue: unknown) => {
  if (!Array.isArray(devValue) || !Array.isArray(ftValue)) return undefined;

  // plain-value arrays like enum and required: take the union so nothing is lost
  if (isPureValueArray(devValue) && isPureValueArray(ftValue)) {
    return [...new Set([...devValue, ...ftValue])];
  }
  // arrays of objects or $refs: take the feature branch's array whole
  return ftValue;
};

const merged = mergeWith({}, devSpec, ftSpec, mergeArrayCustomizer);
// then re-merge each operation's parameters with mergeParamsByIdentity

The union has a side effect: if the feature branch removed an enum value on purpose, the union puts it back. The tool can't tell "not synced yet" from "deliberately removed", so I added a warning. Whenever the union keeps values the feature branch doesn't have, it prints the path and the values and lets a human decide. At least it's a visible trade-off now instead of a silent bug.

One more edge case: if the feature branch explicitly says parameters: [] instead of omitting it, the "take the feature branch's object array whole" rule wipes out all of dev's parameters. So the parameter re-merge has to run when either side has parameters, not only when both do.

Other traps

operationIds with auto-added suffixes. To keep operationId unique, the backend's Swagger generator appends _1, _2 to duplicates. But it checks across the whole spec, so two operations under different tags still get suffixed. swagger-typescript-api generates one class per tag, so the frontend ended up calling cancelSubmission1() instead of cancelSubmission().

So before generating, the tool strips the suffix, but only when no other operation in the same tag already uses that name. Otherwise you'd get two methods with the same name in one class:

const match = op.operationId.match(/^(.+)_\d+$/);
if (match) {
  const base = match[1];
  const sameTagConflict = allOps.some(
    (other) => other.operationId === base && other.tags.some((t) => op.tags.includes(t)),
  );
  if (!sameTagConflict) op.operationId = base;
}

null vs undefined. The backend returns null for empty fields, so lots of generated types are T | null. Most frontend code treats those fields as optional (T | undefined), and the two never lined up. We handled it in two layers:

Runtime: an axios response interceptor that strips null or turns it into undefined, and re-types each API's response to match.
Generation: a teammate added an option so the generated types are T | undefined from the start.

The two have to go together. Types that say undefined while runtime still hands you null is worse than either alone. So the tool now also checks that the project has the interceptor wired up when it generates types.

Rewriting files when only the timestamp changed. The generated file's header includes the spec's update time, so any redeploy of the spec rewrote the file even when nothing else changed, filling git diffs with noise. Now it compares content with the timestamp ignored and only writes when something real changed.

Results and takeaways

All nine frontend projects, Next.js sites and React Native apps, now generate types with the same command. Locally, it picks the right spec from your current branch. CI runs the same command, so if the backend API and the frontend's usage disagree, typecheck catches it before it ships.

What I took away from this:

Let a naming convention replace configuration. Same-named branches plus one branch-list endpoint turned "which spec do I need?" into something the tool works out, not something people have to remember.
Don't merge OpenAPI specs with a generic deep merge. Index-based array merging is fine for most config objects but causes subtle bugs in schemas. Merge parameters by name + in, and union enum and required.
Silent errors are worse than loud ones. A bad merge doesn't throw. It just produces a type that looks plausible. Wherever there's a trade-off (like the union bringing back a removed value), print a warning so people can see it.
Write tests from real incidents. For each merge bug, we turned the actual spec fragment that broke into a test and made sure it failed before the fix. That way nobody quietly undoes it later.
Shared tools work best when everyone can change them. I started this tool, but many of the important fixes came from teammates who hit problems in their own projects. The biggest win of pulling the scripts into one package: one person fixes it, nine projects get the fix.

LINE LIFF in a Next.js Frontend: The Pitfalls I Hit

sp0033212000 — Mon, 19 Oct 2026 15:45:45 +0000

The booking site I work on is a Next.js app, and a lot of its users arrive by tapping a link in a shop's LINE Official Account. So we added LIFF early on, letting people sign in with LINE in one tap. Later we moved sign-in to an SSO SPA on a separate domain. That's when LINE's in-app browser and cross-domain redirects started fighting each other: pages stuck on "Loading...", sign-in loops, error popups nobody could make sense of. And many of them only happened on Android, or only on iPhone.

This post collects the LINE pitfalls I ran into, each with the symptom, the cause and the fix. If your site gets opened inside LINE, hopefully it saves you some time.

1. LIFF login in an external browser loops forever on iPhone

Symptom: A user opens the site in Safari on iPhone and taps "Sign in". They get bounced to the LINE app, then back to Safari, and the page still shows the "Sign in" button. Tap it again, same loop.

Cause: When you run the LIFF OAuth flow in an external browser, iOS hands the login over to the LINE app. When LINE hands control back to Safari, it opens a new tab instead of returning to the original one. Everything the OAuth flow needs, like the code verifier stored in the original tab, isn't visible from the new tab, so the flow just breaks.

I tried a few workarounds, including forcing the external-browser OAuth flow and building the OAuth URL by hand with a parameter to stop the app from taking over. None of them worked.

Fix: Only use LIFF login when the page is actually running inside the LINE app. External browsers get a different sign-in method (SMS in our case). For the check I didn't write my own User-Agent rules. LINE publishes @liff/is-in-client, which runs the same logic as liff.isInClient() and doesn't need liff.init() first:

import { isInClient } from '@liff/is-in-client';

export const isLiffInAppBrowser = (): boolean => {
  // It reads navigator and sessionStorage synchronously, so guard SSR
  if (typeof window === 'undefined') return false;
  return isInClient();
};

One related gotcha: make the LIFF login redirectUri point back to the page the user was actually on. In one case we were sending them to the home page, so after signing in with LINE they lost the store page they'd been looking at.

2. `liff.init()` can reload the current URL

Symptom: After signing in, the user lands back on our callback page, and the request that exchanges the one-time code for a token goes out twice. The second one fails with a 400.

Cause: We ran liff.init() on every page load. Inside LINE's in-app browser, liff.init() can navigate to the current URL again. On the callback page, that means reloading with the same single-use code, so the code gets redeemed twice.

Fix: You need both of these:

Don't run liff.init() on the callback page. All that page does is trade a code for a token. It doesn't need LIFF at all.
Redeem each code exactly once. If a remount calls it again, join the request that's already in flight. If the page reloads, reuse the result you recorded instead of calling the API again.

The second point isn't really LINE-specific. Any page that handles a single-use code (OAuth, magic links and so on) should assume it might get loaded twice.

3. Changing `location` before `liff.init()` finishes, and Android never navigates

Symptom: Before redirecting to the sign-in page, we show a "Loading..." overlay. In some Android LINE builds that overlay just stays there forever, and the URL never changes.

Cause: LINE's own docs warn about this: if you touch location in the same tab while liff.init() is still running, some Android LIFF WebViews never actually navigate. Our redirect logic and liff.init() lived in different components, so they raced.

Fix: Wait for liff.init() before redirecting. There's a catch, though: liff.init() has no timeout of its own. If it hangs (say the SDK never finishes loading), waiting on it forever just moves the "stuck on Loading" bug somewhere else. So I wait at most 5 seconds, then redirect anyway:

const LIFF_INIT_WAIT_MS = 5_000;

useEffect(() => {
  // In LIFF, let liff.init() settle before touching location
  if (isLiffMode && !liffReady && !waitElapsed) {
    const timer = setTimeout(() => setWaitElapsed(true), LIFF_INIT_WAIT_MS);
    return () => clearTimeout(timer);
  }
  startRedirect();
}, [isLiffMode, liffReady, waitElapsed]);

4. Android LIFF can swallow cross-domain redirects

Symptom: Even after waiting for liff.init(), some Android devices still got stuck. Users who cancelled on the sign-in page also came back to a blank callback page that went nowhere.

Cause: Some Android LIFF browsers silently swallow a same-tab cross-domain location.assign() or location.replace(). No error, the tab stays alive, it just doesn't go anywhere.

Fix: I couldn't fix this at the root, so the code checks whether the redirect took, and tries again if it didn't:

const REDIRECT_RETRY_MS = 2_000;

export const redirectWithRetry = (url: string, onStuck?: () => void) => {
  window.location.assign(url);
  // Still on this page after 2 seconds? Try again
  setTimeout(() => {
    window.location.assign(url);
    // If that didn't work either, let the caller show a manual retry button
    if (onStuck) setTimeout(onStuck, REDIRECT_RETRY_MS);
  }, REDIRECT_RETRY_MS);
};

If the redirect does go through, the page is gone and the timers never fire, so there's no need for an extra check. onStuck is the last line of defense: if there's a loading overlay on screen, the user at least gets a button to retry, instead of staring at it forever.

5. LIFF APIs only work after `init()` finishes

Symptom: After a booking, we use liff.sendMessages() to post a booking summary into the user's chat. Sentry kept reporting errors from that spot.

Cause: The code used liff.isLoggedIn() to decide whether it could send. But the liff object exists as soon as you import it. That doesn't mean it has been initialized. Before init() finishes, or if it never runs at all (say the user opened the site in an external browser), those APIs aren't usable.

Fix:

Don't use the presence of the liff object as your check. Track your own "init finished" flag and only call other LIFF APIs once it's true.
For nice-to-have features like sendMessages(), just log the failure. Don't let it interrupt the booking flow.

What debugging taught me

With all of these, the time went into finding the cause, not writing the fix. A few lessons worth writing down:

1. Don't alert() raw errors at users. For a while, users inside LINE kept seeing popups like "TypeError: Load failed" and "Network Error". My first theory was a LINE redirect timing issue, so I tried delaying redirects by a few seconds. That did nothing. Testing on a real device eventually showed the page was navigating away while liff.init() still had requests in flight. The interrupted request threw, and there happened to be an alert(e) in that code path. But a failed liff.init() already falls back to SMS sign-in, so the popup told users nothing useful. Removing it fixed it.

2. Check your own monitoring config. The "stuck on Loading" bug produced zero errors in Sentry. It turned out ignoreErrors was dropping Network Error, Load failed and friends in every environment, staging included. The errors we'd filtered out to cut noise were exactly the ones I was hunting. Now they're only ignored in production.

3. Some errors aren't yours. Sentry also had a steady stream of TypeErrors about window.webkit.messageHandlers being undefined. They came from a third-party script (most likely a tag in GTM) running inside Instagram's and Facebook's in-app browsers. It assumed it was inside a native app's WebView and tried to call a native bridge that doesn't exist on pagehide. By then the user has already left, it isn't our code, and there's nothing to fix, so it gets filtered in Sentry.

4. No DevTools on the device? Put the console on the page. Load vConsole or eruda outside production and you can read logs right inside LINE. In LINE's in-app browser, that's close to essential.

Checklist

If your site gets opened inside LINE, run through these:

Only use LIFF login inside the LINE app; give external browsers another way in, and check with @liff/is-in-client
Point the LIFF login redirectUri back at the page the user was on
Don't run liff.init() on a callback page that redeems a one-time code, and redeem each code exactly once
Wait for liff.init() before changing location, but cap the wait
Check that cross-domain redirects actually happened, retry if not, and give users a manual retry as a last resort
Only call other LIFF APIs after init, and don't let nice-to-have features break the main flow
Don't alert() raw errors, and make sure your monitoring isn't ignoring the errors you're looking for

LINE's in-app browser behaves differently from a normal browser in a lot of ways, and Android and iPhone differ from each other on top of that. My biggest takeaway: anything people will use inside LINE needs to be tested inside the real LINE app, on both kinds of phone.

References:

Passkeys in In-App Browsers: The API Is There, but It Won't Work

sp0033212000 — Mon, 19 Oct 2026 15:20:14 +0000

I recently added passkeys to a member login page, and LINE's in-app browser gave me one of the sneakiest bugs I've dealt with in a while. The passkey button showed up. Tapping it did nothing. No system prompt, no error, nothing in the console.

This post walks through what was going on, plus three things I think anyone shipping passkeys should know: how to tell whether passkeys will actually work, why NotAllowedError doesn't mean the user cancelled, and why a null from your backend can make Safari throw before the ceremony even starts. All the code is ready to copy. If your site gets opened from inside LINE, Facebook, Instagram or similar apps, this probably applies to you.

The symptom

While testing on staging, I opened the login page inside LINE. The passkey button was there, but tapping it did nothing at all.

With no error to look at, I started with a screen recording and stepped through it frame by frame. The "verifying" state showed up for exactly one frame at 30fps. So navigator.credentials.get() was being called, and it was failing within a few dozen milliseconds. Why was the screen blank? Because our code treated every NotAllowedError as "the user cancelled", and a cancel shouldn't show an error. The failure was being swallowed.

Next I added logging on a real device. On iOS 26.6 with LINE 26.12.1, I got this:

supported()  = true          // the shallow check passes
IUVPAA       = false (12ms)  // the platform honestly says no
get()        -> NotAllowedError after 4ms

Nobody cancels anything in 4ms. The system prompt hadn't even been drawn yet. LINE's WebView exposes the WebAuthn API, but it doesn't actually let you use it. That's decided by the host app and the OS, and nothing on the page can change it.

1. Checking that the API exists isn't enough

A lot of tutorials decide whether to offer passkeys like this:

if (window.PublicKeyCredential) {
  // show the passkey button
}

That's fine in a regular browser. In an in-app browser it isn't. The WebView usually runs on the system's browser engine, so the API is there, but whether a ceremony can actually run is up to the app wrapping it.

The more reliable approach is to ask the platform whether it can do this right now. There are two APIs for that:

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() asks whether the device has a platform authenticator that can verify the user (Face ID, a fingerprint reader, Windows Hello). It's widely supported.
PublicKeyCredential.getClientCapabilities() is newer, from WebAuthn Level 3, and returns a whole set of capabilities at once. It needs Chrome or Edge 133, Firefox 135, or Safari 17.4.

Inside LINE, the first one honestly returns false. Use it to decide whether to show the passkey option, and the dead button goes away. Here's the version I ended up with:

const PROBE_TIMEOUT_MS = 3000;
let capability: Promise<boolean> | undefined;

// Cached, so the page only asks once
export function canUsePasskey(): Promise<boolean> {
  capability ??= probe();
  return capability;
}

async function probe(): Promise<boolean> {
  const PKC = window.PublicKeyCredential as any;
  if (!PKC || !navigator.credentials?.get) return false;

  // Newer API: prefer it when it's there
  if (typeof PKC.getClientCapabilities === 'function') {
    const caps = await withTimeout(PKC.getClientCapabilities(), PROBE_TIMEOUT_MS);
    if (typeof caps?.userVerifyingPlatformAuthenticator === 'boolean') {
      return caps.userVerifyingPlatformAuthenticator;
    }
  }

  // Older API: much wider support
  if (typeof PKC.isUserVerifyingPlatformAuthenticatorAvailable !== 'function') {
    return false;
  }
  return (
    (await withTimeout(
      PKC.isUserVerifyingPlatformAuthenticatorAvailable(),
      PROBE_TIMEOUT_MS,
    )) === true
  );
}

// Some restricted WebViews return a promise that never settles
function withTimeout<T>(p: Promise<T>, ms: number): Promise<T | undefined> {
  return Promise.race([
    p.catch(() => undefined),
    new Promise<undefined>((resolve) => setTimeout(() => resolve(undefined), ms)),
  ]);
}

A few notes on why it looks like this:

The timeout isn't optional. Some restricted WebViews hand back a promise that never resolves or rejects. Without a timeout, your login page just hangs on the check.
Cache it. Login, enrollment and passkey management all need the answer, so ask once.
getClientCapabilities() can return undefined for a key, which means the browser doesn't know. In that case it falls back to the older API. In my own project I only use the older API, and I've confirmed it returns false inside LINE. I haven't verified what the newer one returns across different apps' WebViews, so test it on real devices before relying on it.

Why not just sniff the User-Agent for LINE? Because the platform already gives you an honest answer, and UA rules rot as apps ship new versions. If LINE ever enables passkeys, a UA check would keep those users locked out. The trade-off is that a desktop with only a USB security key and no Touch ID or Windows Hello gets filtered out too. For a phone-first product, I'm fine with that.

2. `NotAllowedError` doesn't mean the user cancelled

The reason the failure was invisible in the first place: the code mapped every NotAllowedError to "user cancelled". That's a really common pattern, but NotAllowedError covers a lot more than that. The user closing the prompt, the request timing out, no usable credential, and, as here, the environment refusing outright can all come back as the same error.

That's on purpose. If every failure had its own error, a site could use them to figure out whether a given credential exists on the device, and identify the user without their consent. So the browser won't tell you the exact reason, and you have to infer it.

The most useful signal turns out to be time. To cancel, a person has to see the system prompt and tap cancel. That can't happen in a few milliseconds. So I time the call, and anything rejected too quickly counts as "passkeys don't work here", and the user gets pointed to another way to sign in:

// Nobody can see a system prompt and dismiss it in under 300ms
const HUMAN_CANCEL_FLOOR_MS = 300;

export type PasskeyFailure = 'cancelled' | 'unavailable' | 'error';

export async function getPasskeyAssertion(options: CredentialRequestOptions) {
  const started = performance.now();
  try {
    return await navigator.credentials.get(options);
  } catch (err) {
    const elapsed = performance.now() - started;
    console.warn(`[passkey] rejected after ${Math.round(elapsed)}ms`, err);

    if (err instanceof DOMException && err.name === 'NotAllowedError') {
      const reason: PasskeyFailure =
        elapsed < HUMAN_CANCEL_FLOOR_MS ? 'unavailable' : 'cancelled';
      throw Object.assign(new Error(reason), { reason });
    }
    throw Object.assign(new Error('error'), { reason: 'error' as PasskeyFailure });
  }
}

On unavailable, show something like "Passkeys aren't supported here, try signing in with SMS". Only on cancelled should you stay quiet.

Where does 300ms come from? The rejection I measured in LINE took 4ms, so 300ms leaves about 75 times that margin and still sits well below how long a real person takes to cancel. It's a heuristic, though, not something the spec guarantees. It also only makes sense for the modal flow. If you use conditional mediation (passkeys in the autofill dropdown), there's no prompt to time, so don't apply it there.

In theory the check from section 1 already filters these environments out. This is the backstop for any WebView that lies about its capabilities, so you never ship another button that does nothing.

3. A `null` from the backend, a TypeError from Safari

Around the same time I hit a second passkey bug. During registration, Safari and Chrome on iOS 18 threw a TypeError before the system prompt ever appeared.

The backend was serializing unset WebAuthn fields as explicit null instead of leaving them out:

{
  "authenticatorSelection": {
    "residentKey": null,
    "userVerification": "preferred"
  }
}

In JavaScript, null and "not there" feel interchangeable. The browser doesn't see it that way. It converts your options into WebAuthn's types using WebIDL rules, and some of those fields don't accept null. An explicit null fails the conversion and throws, while a missing field just gets its default.

The fix is simple. Strip the nulls before handing the options to the browser:

function stripNulls<T>(value: T): T {
  if (Array.isArray(value)) return value.map(stripNulls) as T;
  if (value && typeof value === 'object' && !ArrayBuffer.isView(value) && !(value instanceof ArrayBuffer)) {
    return Object.fromEntries(
      Object.entries(value)
        .filter(([, v]) => v !== null)
        .map(([k, v]) => [k, stripNulls(v)]),
    ) as T;
  }
  return value;
}

await navigator.credentials.create({ publicKey: stripNulls(creationOptions) });

The real fix is for the backend to stop sending nulls. But a small guard on the frontend means you don't have to worry about the next empty field someone adds.

If you really need passkeys inside LINE

Once you've detected that passkeys won't work, falling back to SMS or email isn't the only option. You can also send the user to their default browser. LINE supports a URL parameter, openExternalBrowser=1, that makes a link tapped inside LINE open in the external browser instead:

https://example.com/login?openExternalBrowser=1

It doesn't apply to LIFF apps, and it takes the user out of LINE, so whether it's worth it depends on your product.

Debugging inside in-app browsers

The hard part this time wasn't the fix. It was not being able to see the error. You can't attach DevTools to an in-app browser, so here's what helped:

Turn on eruda outside production. It drops a small console onto the page so you can read logs on the phone itself. Load it after the page's load event so it doesn't interfere with what you're trying to observe.
Log the environment first. On page load, dump the UA, the origin, whether PublicKeyCredential and friends exist, and what the capability check returned. That one set of numbers is what cracked this bug.
Count frames in a screen recording. Before you have any logging, step through a recording frame by frame to see how long a state actually lasts. A one-frame "verifying" state is what told me the call was failing, rather than the button not being wired up.
Log the decision before you act on it. For the 300ms threshold, I first had the code just log what the threshold would have decided. Only after the numbers looked right on real devices did I let it change behavior.

Checklist

If your site gets opened inside in-app browsers, here's what to check when you ship passkeys:

[ ] Use getClientCapabilities() or isUserVerifyingPlatformAuthenticatorAvailable() to decide whether to show passkeys, not just whether the API exists
[ ] Put a timeout on the check and cache the result
[ ] Don't treat every NotAllowedError as a cancel; give users a way out when it's rejected too fast
[ ] Strip null fields before calling navigator.credentials
[ ] Test inside the actual apps on real devices; desktop emulation won't catch any of this

References:

Team of One: Fixing a Broken Test Suite Between Feature Requests

sp0033212000 — Mon, 19 Oct 2026 04:02:39 +0000

In September I ran yarn test on our NestJS API and 71 of 87 suites failed.

Honestly, I wasn't surprised. I'm the only engineer at the company, so the website, the back office, the API and every deploy are on me. When a feature request comes in, the feature gets built first and the tests wait. And since CI never ran the tests, nobody knew they were broken.

But being the only engineer also means nobody reviews my code. Tests are the only safety net I've got. So I started fixing them in the gaps between feature work, a bit at a time. By the end of the month the suite was green, it ran in 95 seconds instead of 335, and a failing test blocked the deploy. This post is about how I decided what to fix first, and what not to fix at all, when there wasn't much time to go around.

How it got that bad

The API runs on Cloud Run and deploys through Cloud Build, which had two steps: build the image, deploy it. Tests never ran, so they quietly rotted.

Almost every failure looked like this, before a single assertion ran:

Nest can't resolve dependencies of the RentalService
(PrismaService, GoogleService, FormatHelperService, GoogleMapService, ?, UserService).
Please make sure that the argument SystemService at index [4] is available...

The one that hurt was the rental service spec. It had 19 tests covering real business logic, and they used to pass. Then SystemService was added to the constructor and all 19 broke. With 70 other suites already red, nobody noticed. Me included.

Short on time, so save what matters

I didn't have time to fix 71 suites one by one, so the first step was triage: which of these were actually worth my time?

69 of them were Nest CLI scaffolding. nest g service generates a spec with a single it('should be defined') and provides the service without any of its dependencies, so any service with a constructor argument fails from day one. These had never passed.

That raised the obvious question: should I even keep them? My test was simple. If I delete this file, do we lose anything we know about how the code behaves? A should be defined stub only checks that Nest can wire the class, and the app already proves that every time it starts. Keeping them would mean a mock list per service, updated on every constructor change. For a team of one that cost is way too high, and the fact that it hadn't happened 69 times says it all.

So I fixed the 21 real tests first. The rental spec just needed mocks for its new dependencies. The listing controller spec was failing because AuthGuard needed a UserService. Instead of providing it, I overrode the guard:

const module = await Test.createTestingModule({
  controllers: [ListingController],
  providers: [{ provide: ListingService, useValue: listingServiceMock }],
})
  .overrideGuard(AuthGuard)
  .useValue({ canActivate: () => true })
  .compile();

Guard behavior belongs in the auth module's own tests. Making every controller spec deal with the guard's dependencies is exactly what broke this one. With the override in place, future changes to the guard won't break controller tests, and I won't have to come back and fix them.

I kept the stubs for five core modules: listing, rental, users, webhook and auth. They handle data and permissions, so a broken constructor there hurts the most, and that's a maintenance cost I'm willing to pay. The other 62 went. I thought about describe.skip, but that just turns the screen green. The problem stays, and I'd have to deal with it all over again later.

Last, I ran the suite with the database URL and LINE credentials blanked out. Still green, so every test was properly mocked and CI wouldn't need any secrets.

Make a failing test block the deploy

Fixing the tests was only half the job. Nobody reviews my code, so without something forcing the issue, tests would start breaking again the next time I'm rushing a feature. Once the suite was green, I added a test step at the start of Cloud Build. Cloud Build stops at the first failing step, so a failing test means no image and no deploy.

Its first three runs on staging all failed, each for a different reason, and none of them reproduced on my laptop:

The Prisma client wasn't generated in the CI container, so every model type was missing. Fix: run prisma generate before the tests.
Jest ran out of memory while type-checking the generated client. Fix: raise Node's heap size and recycle workers with --workerIdleMemoryLimit.
One module created an SDK client from credentials at import time and crashed before any test ran. Fix: dummy values for those variables in CI.

Moving the tests to GitHub Actions

Running tests in Cloud Build worked, but every build reinstalled dependencies the Dockerfile had already cached, and failures were buried in the Cloud Build logs. Digging through those every time adds up when you're the only one doing it. So I moved the tests to GitHub Actions. The workflow only starts Cloud Build after the tests pass, and a failure shows up as a red X right on the commit.

The catch is that the build no longer protects itself. It's up to the workflow to make sure only tested commits get deployed. The relevant parts look like this:

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false

jobs:
  test:
    strategy:
      fail-fast: true
      matrix:
        shard: [1, 2, 3]
    steps:
      # checkout, setup-node, yarn install, prisma generate
      - run: yarn test --ci --shard=${{ matrix.shard }}/3

  deploy:
    needs: test
    permissions:
      id-token: write
    steps:
      # authenticate with Workload Identity Federation
      - run: gcloud builds triggers run "$TRIGGER" --sha="${{ github.sha }}" ...

--sha builds the commit that passed. Without it, triggers run builds whatever the branch points to at that moment, so if I push again while the tests are running, the newer, untested commit gets deployed.
The per-branch concurrency group, with the deploy job waiting for the build to finish, means an older build can never land after a newer one and overwrite it.
Workload Identity Federation means there's no service account key stored in GitHub, which is one less secret to manage or worry about leaking. Only this repo's staging and main branches can get credentials.
GitHub's runner was noticeably slower than Cloud Build, and a single test job would have made deploys slower than before, so the suite runs as three parallel shards.

I also used triggers run rather than gcloud builds submit. submit uploads the working directory as the build source, and after a test run that directory is full of node_modules.

Checking that it works

I pushed a test I'd broken on purpose. One shard failed, the deploy job was skipped, and Cloud Build never saw that commit. That's when I actually trusted it.

The first timed run caught a mistake of mine too. Push to deploy took over 18 minutes, and it turned out I'd forgotten to remove the old test step from Cloud Build, so every commit was being tested twice. After removing it, it came down to about 12.

Where it ended up

	Before	After
Failing test suites	71 of 87	0 of 25
Test run	335 s	95 s
Tests block deploys	No	Yes
Where failures show	Nowhere	A red X on the commit
Push to production	~10 min, untested	~12 min, tested

Deploys take about as long as before, but every one is tested now, and the whole thing runs without me babysitting it. When you're the only engineer, that matters a lot more than saving a few minutes. If I were starting over, I'd add the gate on day one. Everything in this post is me catching up on what I didn't do back then.

DEV Community: sp0033212000

Generating API Types When Frontend and Backend Both Live on Feature Branches

The core idea: same-named branches

The basics: one config file, one command

Merging two specs: don't just deep merge

Other traps

Results and takeaways

LINE LIFF in a Next.js Frontend: The Pitfalls I Hit

1. LIFF login in an external browser loops forever on iPhone

2. liff.init() can reload the current URL

3. Changing location before liff.init() finishes, and Android never navigates

4. Android LIFF can swallow cross-domain redirects

5. LIFF APIs only work after init() finishes

What debugging taught me

Checklist

Passkeys in In-App Browsers: The API Is There, but It Won't Work

The symptom

1. Checking that the API exists isn't enough

2. NotAllowedError doesn't mean the user cancelled

3. A null from the backend, a TypeError from Safari

If you really need passkeys inside LINE

Debugging inside in-app browsers

Checklist

Team of One: Fixing a Broken Test Suite Between Feature Requests

How it got that bad

Short on time, so save what matters

Make a failing test block the deploy

Moving the tests to GitHub Actions

Checking that it works

Where it ended up

2. `liff.init()` can reload the current URL

3. Changing `location` before `liff.init()` finishes, and Android never navigates

5. LIFF APIs only work after `init()` finishes

2. `NotAllowedError` doesn't mean the user cancelled

3. A `null` from the backend, a TypeError from Safari