DEV Community: Hardil Singh

My WSL2 VM Kept Losing Network Every Five Minutes

Hardil Singh — Sat, 25 Jul 2026 18:01:29 +0000

Every five minutes or so, my entire Windows machine would drop off the network for a few seconds — not just WSL, the whole host. Browser tabs would stall, calls would drop, and it only happened while WSL2 was running. This is the story of finding that, plus the WSL memory-tuning landmines I hit right alongside it.

The flapping

The symptom was a host-wide network blip on a short, regular interval, correlated tightly with WSL2 being up. The cause: WSL2's default networking mode creates a virtual NAT switch on the Windows side, and on this machine that virtual switch was intermittently conflicting with the real network adapter — enough to cause the whole host to briefly renegotiate its connection.

The fix was switching WSL2's networking mode entirely, via .wslconfig (on Windows, not inside the Linux filesystem):

[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true

Mirrored networking makes the WSL2 interface share the host's actual network identity instead of sitting behind a separate virtual NAT switch. You can confirm it actually took effect (rather than just trusting the config file) by checking, from inside WSL after a full restart, that its network interface holds the same IP as the Windows host, that the default route points at the real LAN gateway rather than a private NAT range, and that loopback carries mirrored mode's marker address rather than a 172.x NAT address. If any of those don't match, the setting isn't actually active yet.

Worth noting: this requires a reasonably recent WSL version and Windows build. If you're on an older one, mirrored mode may not be available at all.

The memory landmines, found the hard way

Separately — and this had actually caused full VM crashes, not just hangs, at one point — I'd been carrying a few .wslconfig settings that looked reasonable and were each, individually, a documented source of instability:

An explicit kernelCommandLine override.
Resizing swap past a few GB, which forces WSL to rebuild its virtual disk and can leave things in a bad state mid-rebuild.
[experimental] autoMemoryReclaim=gradual — has documented freeze bugs in the versions I was on.

Any one of these coinciding with a memory-constrained session was enough to take the WSL VM down hard enough that it wouldn't restart cleanly — the actual failure mode was a service-level "catastrophic failure" error, not just a slow hang.

The safe way to adjust swappiness, instead of a kernel command-line flag, is a plain sysctl drop-in that gets applied on every boot:

# /etc/sysctl.d/99-swappiness.conf
vm.swappiness=10

Recovery, when it won't come back up at all

If WSL refuses to launch after something like this:

Close the terminal window outright. Don't keep hitting Enter — that just re-hits whatever service is already wedged.
From PowerShell: wsl --shutdown, then wait a beat before trying again.
If it's still refusing: restart the underlying WSL service (as admin), then wsl --update.
If it's still unhappy: quit anything with its own WSL integration (a container runtime, for instance) and test again — integrations like that are a common second point of contention over the same resources.

What I'd tell past-me

A periodic, host-wide network blip that correlates with a VM being up is almost always that VM's networking mode, not your actual network hardware — don't start troubleshooting the router.
Verify a networking-mode config change actually took effect (interface, route, loopback marker) instead of assuming the file being correct means the behavior changed.
Some "obvious" tuning flags for a VM are documented landmines. Change one at a time, and check what's actually been reported broken about it before adding it.
When recovery is needed, follow the same escalation path in order — don't jump straight to the most drastic fix before ruling out the cheap ones.

What Durable Actually Means for Money-Critical Code

Hardil Singh — Sat, 25 Jul 2026 18:00:53 +0000

Working on systems that move real money changes what "saved to the database" is allowed to mean. A row existing in Postgres is not the same claim as "this record is durable and this record is true." Here's the pattern I now apply to any code where a mutation has to be trusted after the fact — balances, ledgers, anything that gets audited.

One choke point, always

Every mutation of critical state — a credit, a debit, a transfer, a reversal — goes through exactly one audited function. Not "usually," not "except for this one admin shortcut." One function, and every caller, including internal tooling, goes through it. The moment a second code path can also mutate the balance, the ledger stops being a source of truth and becomes one of several competing opinions about what happened.

Caches are allowed to exist for read performance. They are never allowed to diverge from the ledger, and they're never the thing you trust when reconstructing history.

Append-only and hash-chained, not just "logged"

A row that can be edited or deleted after the fact isn't a record, it's a draft. Each ledger entry includes a hash of the previous entry, so any modification to history — not just deletion, but an in-place edit of an old row — breaks the chain and is immediately detectable. Where the integrity guarantee needs to be verifiable by someone outside the system (a counterparty, an auditor, a regulator), the chain gets signed, verifiable with a public key and no shared secret required.

Durable means it survives a crash between "accepted" and "written"

A record isn't durable the moment your code decides to write it — it's durable once it's actually persisted somewhere that survives a crash. The gap between those two moments is where money quietly disappears in systems that don't think about it. The pattern: a durable enqueue with a local write-ahead-log fallback, so if the primary write path fails partway, nothing is silently dropped — it gets recovered and replayed on the next boot.

Nothing that's genuinely "of record" is allowed to live only in memory. If a process restart can make a transaction vanish, it was never actually recorded — it was a promise.

Sequence gaps are fine to detect; collisions are not fine to allow

Sequence or ID design should make gaps detectable — a monotonic counter where a skipped number is a visible anomaly worth investigating — while making collisions structurally impossible, not just statistically unlikely. A detectable gap is an incident to review. A silent collision is corrupted history.

Decoupling the hot path from the database

Under load, the request/response path should never be gated on a synchronous database write. High-frequency or non-critical events go through a durable, backpressured queue with a single batched writer — bursts queue up, the database sees smooth load instead of a spike, and nothing on the user-facing path stalls waiting on persistence. The queue is still durable end to end; "decoupled" doesn't mean "best-effort."

Fairness needs the same rigor as money

Anywhere an outcome has to be provably fair (a random draw, a game result, anything adjudicated after the fact), the seed has to come from a real CSPRNG, generated per-event — never a fixed value, and never derived from something observable or predictable like the system clock. Log the seed and the ruleset in force at the time, so a disputed outcome can actually be reconstructed and verified later, not just asserted.

What I'd tell past-me

"It's in Postgres" is not the same claim as "it's durable." Ask what happens if the process dies one line after the write call.
A single audited choke point isn't bureaucracy — it's the only way "reconstruct what happened from the ledger alone" stays true as the codebase grows.
Build the tamper-evidence in from the start. Retrofitting a hash chain onto years of mutable history is a much harder project than doing it on day one.

The Auth Pattern I Copy Into Every New Project Now

Hardil Singh — Sat, 25 Jul 2026 18:00:16 +0000

I stopped deciding auth architecture from scratch on every new project. After enough rounds of the same debate — "can we just put the JWT in localStorage for now?" — I settled on one hardened pattern and now I just apply it every time, tweaking only where the app needs a Bearer-token escape hatch (mobile clients, third-party API consumers).

Here's the pattern, and why each piece is there.

The core decision: httpOnly cookie, never JS-readable storage

The session token gets issued in an httpOnly + Secure + SameSite=Lax cookie, domain-scoped so it works across subdomains. It never touches localStorage, sessionStorage, or any JS-readable variable.

The reason is simple: anything readable by JavaScript is readable by an XSS payload. An httpOnly cookie is invisible to document.cookie and to any script running on the page, malicious or not. It's not a nice-to-have — it's the difference between "one XSS bug leaks a session" and "one XSS bug leaks nothing session-related."

CSRF double-submit, only where it's needed

Cookie-based auth reintroduces CSRF risk that a Bearer token in a header doesn't have (a browser attaches cookies automatically; it doesn't automatically attach a custom header). So: a second, JS-readable cookie carries a CSRF value, and the frontend echoes it back as a request header on every mutation. The server checks the two match. This only needs to guard mutations — reads don't need it — and it doesn't apply at all to pure Bearer-token clients, since they were never vulnerable to it in the first place.

CORS: allowlist, never wildcard, especially with credentials

Access-Control-Allow-Origin: * combined with credentials: true is a combination that should never exist — it effectively lets any site ride your users' sessions. The fix is an explicit origin allowlist with credentials: true, never a wildcard and never a reflected-origin shortcut that accepts whatever Origin header shows up.

TOTP 2FA for anything privileged

Any role with elevated access gets standard TOTP setup/enable/disable, required at login once enabled. Cheap to implement, disproportionately valuable for admin/privileged accounts specifically.

Migrating an existing Bearer-token app without breaking it mid-cutover

This is the part that actually made the pattern practical to adopt, not just design: when a live app already uses Bearer tokens, the migration goes dual-mode. Auth guards accept either the httpOnly cookie or the Authorization header; CSRF checks apply only to the cookie path. The login endpoint keeps returning the token in the response body (for existing Bearer clients) while also setting the cookie. Nothing breaks for existing integrations while the frontend migrates over incrementally.

The verification checklist, every time

Before calling this "done" on a given app:

Login actually sets an httpOnly cookie (check response headers, not just "it seems to work").
Cookie-based requests succeed without a manually attached token.
A mutation request missing the CSRF header gets rejected (403), not silently allowed.
A request from a disallowed origin gets no Access-Control-Allow-Origin header at all.
Logout actually clears both cookies, not just the session server-side.

Skipping any one of those checks is how "we implemented CSRF protection" quietly becomes "we implemented a CSRF header nobody validates."

What I'd tell past-me

Decide the auth pattern once, well, and reuse it — don't re-litigate localStorage-vs-cookie on every new project.
The CORS+credentials wildcard combination is the single easiest way to accidentally build a session-hijacking vulnerability. Make it impossible to ship, not just documented as wrong.
A migration plan that keeps old clients working is what actually gets a hardened pattern adopted on a live app — "just rewrite it" proposals die in planning meetings.

My Terminal Became an Ops Center, One Command at a Time

Hardil Singh — Sat, 25 Jul 2026 17:59:40 +0000

None of this was designed. Every command in my shell profile exists because I got annoyed at typing the same multi-step sequence one too many times, and each one is small enough that it took twenty minutes to write and has saved hours since.

Here's what accumulated, roughly in the order the annoyance struck:

`infra` — server ops without memorizing which container is which

I run a decent number of containers on a shared server across a few side projects. docker ps, scrolling to find the right name, remembering the exact docker exec incantation — fine once, tedious the fiftieth time. Now it's one word plus a fuzzy-picker:

infra status     # uptime, disk, mem, every container's health, one screen
infra ps [name]  # fuzzy-pick a container if no name given
infra logs / restart / exec [name]
infra stats

`dev` — stop typing "which package manager does this repo use"

Different repos on my machine use different lockfiles, which means different install/run commands. dev just detects the lockfile, cds into the project, and starts the right dev server — pnpm, yarn, npm, whichever it actually is. One word instead of "wait, is this the pnpm one or the npm one."

`brief` — the one-word morning check

Server health, a genuine-unread email count (more on that below), dotfile backup status, and open pull requests — one command, run once, first thing. Before this existed my morning was four separate commands across three terminals just to answer "is anything on fire."

`work` — a consistent workspace per project

Attaching to (or creating) a per-project terminal multiplexer session: one pane for a shell, one pre-loaded with the dev server, one running a terminal git UI. Same layout every time, for every project, instead of rebuilding the same three panes by hand.

`funnel` — exposing a local port to the internet, safely, on demand

For testing webhooks (payment provider callbacks, that kind of thing) against code running on my own machine, I needed a real public HTTPS URL pointed at a local port, without standing up a deploy. A mesh VPN's "funnel" feature does exactly this — funnel <port> streams requests live for a demo, funnel bg <port> runs detached for something like a webhook listener, funnel off tears it down. No DNS, no server, gone the moment I don't need it.

`inbox` — a real signal-to-noise filter for email

Fifteen years of accumulated newsletter/social noise makes a normal inbox useless as a signal. inbox runs a targeted search (unread, primary category, recent, ignoring spam/promotions) and gives me an actual count of things that matter, plus a fuzzy-picker to read one without opening a mail client at all.

`cheat` — because I kept forgetting my own tools

The one that ties it together: a small, colorized cheat sheet of every command above, shown automatically on every new terminal. Building a dozen conveniences is pointless if you forget half of them exist three weeks later. This one's less about functionality and more about actually retaining the value of everything else on this list.

What I'd tell past-me

The bar for "worth automating" isn't "this is hard" — it's "I've now typed this exact multi-step sequence three times."
A one-word command with a fuzzy-picker beats memorizing exact names or flags every time.
Build the reminder (cheat) alongside the tools, not after. Tooling you forget about might as well not exist.
Small, single-purpose shell functions compound. None of these took long individually; together they're most of my daily workflow now.

Building a Claude Code Setup That Stops Me From Shooting Myself in the Foot

Hardil Singh — Sat, 25 Jul 2026 17:59:03 +0000

Every time I hit a bug painful enough to remember, I've started asking the same question: how do I make sure my AI coding assistant never reintroduces it, even months from now, even in a repo it's never seen? Writing it down in a notes file isn't enough — notes get skimmed, context gets summarized, details get lost. So I built a small set of hooks that block specific, known-bad patterns outright, before they ever land.

The idea: hard-won lessons should be enforced, not remembered

A memory note is a suggestion. A hook that runs on every file write and blocks the write with a nonzero exit code is a rule. I only promote something to a hard rule once it's actually cost me real time — this isn't a wishlist of best practices, it's a short list of specific incidents.

Right now that list blocks things like:

A specific dependency-import pattern that once pulled ~9,000 modules into a dev server's compile graph and hung an entire VM (the exact "convenient" import path stays blocked; importing the same package normally is fine).
Container state getting bind-mounted into a repo's working tree as a root-owned directory — it silently breaks file watchers and formatters, and looks like an unrelated tooling bug when it happens.
Writing private key material into any file.
Wildcard or reflected CORS origins paired with credentials: true.
Auth tokens written to localStorage/sessionStorage.
An RNG seed derived from the system clock, anywhere near code that needs to be fair or unpredictable.

Each of those started as "I can't believe that just happened" and ended as four lines in a hook script.

Guarding against a different failure mode: false confidence

The blocking hook stops bad patterns from landing. A separate hook nudges against a subtler failure: declaring something "done" when it hasn't actually been proven. If there are uncommitted source changes in a git repo, it reminds me — once per session, not naggingly — to actually typecheck, run tests, and prove the change works end to end before calling it finished. A model (or a tired human) will happily say "this works" based on the code looking right. Proof is a different bar than plausibility.

Specialists instead of one generalist re-deriving rules every time

The other piece: instead of one assistant trying to hold every domain's rules in its head simultaneously, I split some review responsibilities into narrow specialist reviewers, invoked only when relevant — one that only checks money-handling invariants (does every mutation go through a single audited path, is anything computed in floats that shouldn't be), one that only reviews smart contracts, one that only checks a specific web framework's performance footguns, one that only checks auth/session patterns against a hardened standard. Each one is narrow on purpose. A generalist asked to check "everything" tends to check nothing very deeply; a specialist asked to check one thing tends to actually catch it.

What I'd tell past-me

If something costs you real debugging time once, don't just write it down — figure out if it can be turned into something that mechanically blocks itself from happening again.
Keep the blocklist short and specific. A rule for "don't do the exact thing that hurt me" is enforceable; a rule for "write good code" isn't.
Separate "prevent bad patterns" from "verify claimed completion" — they're different failure modes and deserve different guardrails.
Narrow, specialized reviewers beat one reviewer trying to hold every domain's rules at once.

Why My Deploy Key Lives in a Password Manager, Not on Disk

Hardil Singh — Sat, 25 Jul 2026 17:57:15 +0000

I have an SSH key that has never once existed as a file on my disk. It lives only inside an encrypted password manager vault, and every time it's used, I get a prompt to approve it. Here's why I set that up, and the near-miss that convinced me it was worth the extra friction.

The near-miss

I once pasted a private key into an AI chat window and asked, essentially, "is this the right one?" It felt harmless — I just wanted to confirm an identity before deploying something. It wasn't harmless: the moment a private key is pasted anywhere — a chat, a file, a terminal that logs history — it has to be treated as compromised, because that transcript persists and gets processed elsewhere.

Fortunately it was a freshly generated, not-yet-deployed key. I rotated it immediately — regenerated it, deployed the new one, deleted the old one everywhere — before it was ever used for anything real. But it was a clean demonstration of the actual rule: verify a key's identity by its fingerprint, never by looking at (or pasting) the raw key material.

ssh-keygen -lf ~/.ssh/some_key.pub

That gives you a fingerprint you can compare against what you expect, with zero exposure.

The bigger fix: keys that don't touch disk at all

That incident pushed me to stop keeping my most sensitive deploy key as a plain file at all. My password manager's desktop app already runs its own SSH agent — it can hold a key, unlocked only when I approve it, without ever writing the private material to a file the OS or any process can just read.

The only wrinkle: my dev environment is WSL2, and the password manager's agent lives on the Windows side. Bridging the two took two small pieces:

npiperelay.exe on the Windows side, which exposes a Windows named pipe (the password manager's agent pipe) in a way a Linux process can talk to.
socat on the WSL side, relaying that into a Unix domain socket.

# WSL side, roughly
socat UNIX-LISTEN:$HOME/.ssh/agent-bridge.sock,fork \
  EXEC:"npiperelay.exe //./pipe/openssh-ssh-agent",nofork &

export SSH_AUTH_SOCK=$HOME/.ssh/agent-bridge.sock

Auto-started (guarded so it doesn't spawn duplicates) from my shell profile, so it's just always there. Verify it's working with:

ssh-add -l

Now that specific deploy key exists in exactly one place — the vault — and gets served to ssh only on unlock, with an approval prompt every time it's used. If my laptop disk were imaged tomorrow, that key wouldn't be on it.

Two layers, deliberately not collapsed into one

I keep a clear line between two things that are easy to accidentally merge:

Runtime secrets — the ones tools actually read day to day (API tokens, most SSH keys) — live in gitignored, chmod 600 env files, auto-loaded by my shell profile. Fast, no unlock friction, appropriate for things that aren't catastrophic if a single machine is compromised.
The password manager — backup/escrow, human daily-driver, and the one channel for anything where the blast radius of exposure is severe enough to justify unlock friction on every use (like that one deploy key).

I deliberately didn't architect the runtime layer to fetch everything from the vault on every command. It sounds more secure, but it isn't, really — it just adds friction, and anything a tool or an assistant uses ends up in its working context regardless of which vault it came from. The vault's real value is as an audited, approval-gated path for the handful of secrets where that friction is actually worth paying.

What I'd tell past-me

Never paste a private key anywhere, even to "just check" something — verify by fingerprint instead.
If a key is ever exposed, rotating it immediately isn't overreacting — it's the only response that actually closes the exposure.
Not every secret needs vault-level friction. Reserve it for the few keys where "approve every single use" is a feature, not an annoyance.

The SSH Lockout That Made Me Close Port 22 For Good

Hardil Singh — Sat, 25 Jul 2026 17:57:13 +0000

I got locked out of my own production server. Not "forgot the password" locked out — both SSH and the hosting panel's browser console rejected me, on a box running several live apps, for hours.

Here's what actually happened, and the two lessons that came out of it.

The wrong assumption that cost the first two hours

My hosting provider's browser-based rescue console kept rejecting root's password, even right after resetting it through their panel. I assumed the reset was broken and spent ages fighting it.

It wasn't broken. On a standard Ubuntu cloud image, the account the rescue console logs in as is ubuntu, not root — a convention from how cloud images provision the default user. Root's password can be perfectly correct and still be useless there. On top of that, my ubuntu account turned out to be locked (passwd -S showed L) since the box was created, completely unrelated to any password value.

Two separate, unglamorous facts, neither documented anywhere I'd looked, together cost me two hours.

The second problem, stacked on top

Separately — and this part I never fully root-caused — direct SSH and HTTP to the server's public IP was timing out entirely, not rejecting auth, just hanging. I ruled out the firewall (0 rules at the panel level), fail2ban (ban window had long expired). My best guess: something about the source IP I was connecting from, which rotates on a home/mobile connection. It resolved itself once that IP changed.

The apps themselves never went down — I checked via an external monitor the whole time. Only my own access was blocked.

The actual recovery

When both normal SSH and the console login are dead, most hosting panels have an "Emergency Mode" or rescue mode: it boots a minimal OS and mounts your real disk read/write somewhere like /mnt. From there:

lsblk                       # find the real disk, not the rescue OS's own
mount --bind /dev  /mnt/sdX/dev
mount --bind /proc /mnt/sdX/proc
mount --bind /sys  /mnt/sdX/sys
chroot /mnt/sdX /bin/bash

Inside the chroot, check lock status before touching anything:

passwd -S ubuntu     # L = locked, P = usable
passwd -u ubuntu      # unlock
echo 'ubuntu:newpassword' | chpasswd   # NOT interactive `passwd` here

That last point matters more than it looks: pasting a password into an interactive passwd prompt from a rescue-mode terminal garbled it badly for me the first time. chpasswd piped from echo is the reliable way to do it non-interactively.

One more trap: a lot of panels offer a one-click "reset firewall configuration." It's not a targeted unblock — it fully disables the firewall. Don't reach for it as a first move.

The fix that actually matters

The real fix wasn't unlocking accounts — it was removing the single point of failure that caused this: SSH access tied to a rotating public IP with no fallback path.

I installed Tailscale on the server and on every device I administer it from. Now admin access goes over the tailnet's stable private IP, completely independent of whatever public IP my ISP hands me that day. I deliberately didn't enable Tailscale's own SSH server — sshd stays the single SSH auth surface, Tailscale just becomes the network path to reach it.

Once every CI pipeline that deployed to this box was migrated to connect the same way — join the tailnet as a short-lived tagged node, then SSH over the stable internal IP — I closed the public port 22 rule entirely. SSH is Tailscale-only now, full stop.

One gotcha worth flagging if you do this: a tagged device in Tailscale's ACL is not automatically covered by the default "logged-in members can reach each other" rule. A CI node can join the tailnet fine and still get connection timeouts on the actual SSH attempt, because the tag was never explicitly granted access in the ACL policy. It needs its own explicit grant.

What I'd tell past-me

On a cloud VPS, check the actual console account before assuming it's root — it usually isn't.
Don't let a single rotating IP be your only path to a server. Put a stable, IP-independent access layer (a mesh VPN like Tailscale, or equivalent) in place before you need it, not while you're locked out.
Tagged/automated identities need explicit ACL grants — "it joined the network" and "it can reach anything" are two different guarantees.
A locked-out admin panel doesn't mean a down service — verify what's actually broken (access vs. the app itself) before you start firefighting.

One Icon Import Nearly Took Down My Entire WSL2 Dev Environment

Hardil Singh — Sat, 25 Jul 2026 17:55:21 +0000

One afternoon my mouse froze. Not the app — the whole WSL window. Ctrl+C did nothing. docker ps in another pane just spun. Windows Task Manager showed vmmemWSL sitting at the ceiling and not moving. The only way out was closing every WSL terminal and running wsl --shutdown from PowerShell, then waiting for the VM to fully die before starting it back up.

The trigger, once I found it, was almost funny: I'd added an icon pack for a crypto UI and imported it the "easy" way.

The setup

Next.js 16 on Turbopack, running inside WSL2. The host machine has 16GB of RAM, and I deliberately cap the WSL VM in .wslconfig — a hard memory and swap ceiling — instead of trusting WSL2's default "grow until the host chokes" behavior. Windows needs headroom too; if the VM doesn't have a ceiling, it'll take all of it.

That ceiling is usually a non-issue. next dev compiles routes on demand, memory rises a bit as you click around, and it settles. Until it doesn't.

What actually happened

I needed a handful of chain/token icons and reached for a popular icon package's /dynamic entry point — the one that lets you resolve an icon by symbol at runtime instead of importing each one by name. Convenient. Also, it turns out, a way to hand your dev compiler close to 9,000 modules it didn't need.

Turbopack (like Webpack before it) doesn't know you only want three icons — a dynamic/barrel entry point exposes the whole package as one graph, and the dev compiler has to walk all of it to build the module map, even before you ever click a page that uses it. RSS climbed, GC couldn't keep up, and once we hit the .wslconfig ceiling the VM stopped being responsive to anything, including the shell I was trying to diagnose it from.

The red herring

Here's the part that cost me the most time: next build was completely fine. Green, fast, no warnings.

That's because a production build compiles the graph once and exits — it pays the cost and moves on. next dev instead keeps that graph resident and re-touches it on every file change, for the entire life of the process. A passing build tells you nothing about whether next dev is going to survive an afternoon of work. I'd been checking the wrong signal.

Finding the actual cause

Once I stopped trusting the build and started watching the dev server itself — ps on the next-server process, RSS over time, and which route/import triggered the jump — the pattern was obvious: it wasn't a leak, it was a baseline. The dev server just needed a genuinely huge chunk of memory to hold that module graph, permanently, because that's what the import pulled in.

And it wasn't unique to that one icon package. Any "import one thing from a big indexed package" pattern does this:

import { Icon } from 'some-huge-icon-pack/dynamic' // pulls the whole pack
import { Dialog } from '@radix-ui/react-dialog'     // barrel export
import { useReactTable } from '@tanstack/react-table' // same story

Next ships a default list of packages it already knows to optimize (lucide-react is one), but component-level libraries like individual @radix-ui/* packages and @tanstack/* are not on that list by default.

The actual fixes

1. Stop pulling the whole graph for a few icons. Dropped the /dynamic entry point entirely and either imported the specific icons by name or used dependency-free inline glyphs where a handful of icons didn't justify a whole package.

2. Tell Turbopack explicitly what to optimize. In next.config.ts:

experimental: {
  optimizePackageImports: [
    'lucide-react',
    '@tanstack/react-table',
    '@tanstack/react-query',
    '@radix-ui/react-dialog',
    // every other barrel/indexed import actually in use
  ],
}

This rewrites those imports to their direct file paths at compile time, so the dev compiler only touches what's actually used instead of the whole package. On this repo it took next-server's steady-state RSS from ~3.6GB down to ~1.87GB — about 48% less, just from that one config change. I verified it wasn't a fluke by hammering every route 10x plus sitting idle and watching RSS stay flat afterward — this is a baseline drop, not a leak fix.

One thing that does not help, because it's solving the wrong problem: --max-old-space-size. Turbopack's memory is native Rust, not the V8 heap — bumping the Node heap flag has zero effect on it. The only lever that actually works is fewer/lighter deps plus optimizePackageImports.

3. Cap the blast radius, don't just avoid it. Even with the imports fixed, I kept the explicit .wslconfig memory/swap ceiling. The goal isn't "never hit a limit" — it's "when something does regress, it degrades instead of hanging the whole VM and taking the host down with it."

What I'd tell past-me

A green next build proves nothing about next dev health — they pay completely different costs. Verify dev separately: hammer routes, then let it idle, and watch RSS actually settle.
Treat any /dynamic entry point or barrel/index import from a sizable package as a suspect, not a convenience — check what it actually pulls in before wiring it up.
If you're on WSL2, set an explicit memory + swap ceiling in .wslconfig rather than letting the VM grow unbounded. It won't stop a bad import from being a bad import, but it stops one bad import from being a full-system hang.
If next dev freezes and nothing responds, don't fight it — wsl --shutdown from Windows and start clean. Diagnose after, with the process actually killed.

DEV Community: Hardil Singh

My WSL2 VM Kept Losing Network Every Five Minutes

The flapping

The memory landmines, found the hard way

Recovery, when it won't come back up at all

What I'd tell past-me

What Durable Actually Means for Money-Critical Code

One choke point, always

Append-only and hash-chained, not just "logged"

Durable means it survives a crash between "accepted" and "written"

Sequence gaps are fine to detect; collisions are not fine to allow

Decoupling the hot path from the database

Fairness needs the same rigor as money

What I'd tell past-me

The Auth Pattern I Copy Into Every New Project Now

The core decision: httpOnly cookie, never JS-readable storage

CSRF double-submit, only where it's needed

CORS: allowlist, never wildcard, especially with credentials

TOTP 2FA for anything privileged

Migrating an existing Bearer-token app without breaking it mid-cutover

The verification checklist, every time

What I'd tell past-me

My Terminal Became an Ops Center, One Command at a Time

infra — server ops without memorizing which container is which

dev — stop typing "which package manager does this repo use"

brief — the one-word morning check

work — a consistent workspace per project

funnel — exposing a local port to the internet, safely, on demand

inbox — a real signal-to-noise filter for email

cheat — because I kept forgetting my own tools

What I'd tell past-me

Building a Claude Code Setup That Stops Me From Shooting Myself in the Foot

The idea: hard-won lessons should be enforced, not remembered

Guarding against a different failure mode: false confidence

Specialists instead of one generalist re-deriving rules every time

What I'd tell past-me

Why My Deploy Key Lives in a Password Manager, Not on Disk

The near-miss

The bigger fix: keys that don't touch disk at all

Two layers, deliberately not collapsed into one

What I'd tell past-me

The SSH Lockout That Made Me Close Port 22 For Good

The wrong assumption that cost the first two hours

The second problem, stacked on top

The actual recovery

The fix that actually matters

What I'd tell past-me

One Icon Import Nearly Took Down My Entire WSL2 Dev Environment

The setup

What actually happened

The red herring

Finding the actual cause

The actual fixes

What I'd tell past-me

`infra` — server ops without memorizing which container is which

`dev` — stop typing "which package manager does this repo use"

`brief` — the one-word morning check

`work` — a consistent workspace per project

`funnel` — exposing a local port to the internet, safely, on demand

`inbox` — a real signal-to-noise filter for email

`cheat` — because I kept forgetting my own tools