DEV Community: Dev Encyclopedia

CSS Anchor Positioning: Migrating shadcn/ui Off Radix

Dev Encyclopedia — Sun, 12 Jul 2026 01:43:18 +0000

CSS Anchor Positioning and the native Popover API reached full Baseline support across major browsers in 2026. That means shadcn/ui's Popover and Tooltip, both built on Radix UI primitives, can now be rebuilt with zero JavaScript for positioning.

Radix (via Floating UI) has always handled the hard part: measuring the trigger, calculating placement, listening for scroll/resize, flipping on overflow. That required JS because the browser couldn't do it natively. Now it can.

What you gain and lose

Dimension	Radix + Floating UI	Native CSS Anchor Positioning
Bundle size	Adds a dependency per component	Zero JS for positioning
Runtime cost	Recalculates on scroll/resize	Browser handles it natively
Viewport flip	Floating UI's `flip()` middleware	`position-try-fallbacks`
Focus trapping	Built in	You implement it, or keep Radix
Keyboard nav	Built into Radix	Manual for complex cases
Browser support	Works everywhere JS runs	Needs Baseline 2026 + Safari fallback

For a simple Tooltip or a Popover holding text and a button, native CSS wins outright. For DropdownMenu or Select, keep Radix, the focus trapping and keyboard navigation aren't worth rebuilding by hand yet.

The shape of the migration

The native Popover component uses anchor-name to mark the trigger, anchor() to position the content relative to it, and the browser's built-in popover attribute for top-layer rendering, light-dismiss, and Escape-to-close:

const PopoverContent = React.forwardRef<HTMLDivElement, React.HTMLAttributes<HTMLDivElement>>(
  ({ className, style, ...props }, ref) => {
    const ctx = React.useContext(PopoverContext)
    return (
      <div
        ref={ref}
        id={ctx.contentId}
        popover="auto"
        style={{
          positionAnchor: `--${ctx.triggerId}`,
          top: `anchor(--${ctx.triggerId} bottom)`,
          positionTryFallbacks: "flip-block, flip-inline",
          ...style,
        }}
        {...props}
      />
    )
  }
)

No Portal, no scroll/resize listeners, no Floating UI middleware to configure. popover="auto" gives light-dismiss and Escape-to-close for free. Tooltip follows the same pattern with popover="hint" instead.

One catch: Safari 18.2-18.3 support anchor() but not position-try-fallbacks. Write your base position as a plain value outside the fallback block and it degrades gracefully, no @supports check needed.

Adoption order

Tooltip first - lowest risk, no focus management to preserve
Simple Popovers next - text, single button, one-field forms
Leave DropdownMenu and Select on Radix - the keyboard nav and focus trapping rebuild isn't worth it yet
Measure bundle size before and after each migration to justify the effort

The full post has the complete before/after code for both components, the Safari fallback pattern in detail, and what you still need Radix for:

👉 CSS Anchor Positioning: Migrating shadcn/ui Off Radix

npm postinstall Attacks in 2026: How They Actually Work (and How to Defend Against Them)

Dev Encyclopedia — Thu, 09 Jul 2026 02:51:24 +0000

Every time you run npm install, you're not just downloading files. You're potentially executing arbitrary code, automatically, with your user permissions, before you've looked at a single line of what you just installed.

This isn't theoretical. Since the Shai-Hulud worm first appeared in September 2025, npm supply chain attacks abusing this exact mechanism have kept accelerating. On June 1, 2026, a campaign compromised at least 32 packages under the @redhat-cloud-services npm namespace, bypassing code review entirely through a compromised employee GitHub account.

How the hooks actually work

npm packages can define three install-time hooks in package.json:

preinstall — runs before the package's dependencies are installed
install — runs during the install step itself
postinstall — runs after the package and its dependencies finish installing

{
  "scripts": {
    "postinstall": "node scripts/setup.js"
  }
}

These exist for legit reasons: bcrypt and sharp compile native C++ bindings this way, Puppeteer downloads browser binaries. But npm runs these for every package in your tree, direct or transitive, by default. Only about 2.2% of packages on the registry actually define install scripts, so most of your tree doesn't need this at all. One compromised package in a tree of hundreds is enough.

Roughly how a real attack unfolds

A Microsoft-tracked campaign from May 2026 followed a pattern that's becoming common:

Attacker registers npm packages under lookalike scopes mimicking internal corporate namespaces
An inflated version number wins dependency resolution against your real internal package
A postinstall hook fires an obfuscated script that phones home and drops a payload, before you can intervene

That's the shape of it. The actual obfuscation technique and how the payload survives after the install process exits is where it gets interesting, and where most write-ups stop short.

Why this is genuinely hard to catch

Legit packages need postinstall too, so blanket-flagging trains teams to ignore warnings
Obfuscation makes a 17KB dropper look like nothing on casual review
Cross-ecosystem placement: a May 2026 campaign hid malicious postinstall inside package.json files bundled in PHP/Composer packages, since PHP security reviewers don't think to check bundled JS tooling
The published npm tarball isn't guaranteed to match the GitHub repo. Attackers can publish a malicious tarball while keeping the public repo clean, and almost nobody diffs the two

npm audit and Dependabot are both reactive too. They rely on a CVE already existing. A freshly published malicious package with an obfuscated postinstall script sails through both cleanly.

The mental model worth keeping

npm install is not a download. It's potential code execution. Every dependency you add is code you're agreeing to run, not just import.

I go deep on this in the full write-up: the real obfuscation/C2 pattern from the May 2026 campaign, the monorepo and CI-specific exposure most guides skip, a copy-paste command checklist, and why --ignore-scripts breaks some legit packages (and the workaround for that).

🔗 Full guide: https://devencyclopedia.com/blog/npm-postinstall-attacks-2026

Also built a free tool if you'd rather get a risk-scored report than run manual greps: Lifecycle Hook Scanner

javascript #node #security #webdev

The New HTTP QUERY Method: How to Use It in Node.js and Express Today

Dev Encyclopedia — Wed, 08 Jul 2026 04:00:20 +0000

There's a new HTTP method called QUERY. It's safe like GET (doesn't change data) but can carry a body like POST (so you can send filters). This means search endpoints no longer need the old POST /search trick.

Let's see how to use it in Node.js and Express.

Plain Node.js

Node already understands QUERY, no setup needed.

const http = require('node:http');

const server = http.createServer((req, res) => {
  if (req.method === 'QUERY') {
    let body = '';
    req.on('data', (chunk) => body += chunk);
    req.on('end', () => {
      const filters = JSON.parse(body);
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify({ results: [], filters }));
    });
    return;
  }
  res.writeHead(404);
  res.end();
});

server.listen(3000);

Test with curl:

curl -X QUERY http://localhost:3000 \
  -H "Content-Type: application/json" \
  -d '{"category":"electronics"}'

Express

Express doesn't support app.query() yet, so add a small check before your routes:

const express = require('express');
const app = express();
app.use(express.json());

app.use((req, res, next) => {
  if (req.method === 'QUERY' && req.path === '/products') {
    const filters = req.body;
    return res.json({ results: [], filters });
  }
  next();
});

app.listen(3000);

That's it. express.json() already parses the body, no extra config needed.

One gotcha: CORS

If your frontend and backend are on different domains, add QUERY to your CORS methods, or the browser will silently block it:

app.use(cors({
  methods: ['GET', 'POST', 'QUERY', 'OPTIONS'],
}));

Quick summary

Node.js: works out of the box
Express: needs a small manual check (shown above)
Browsers: support is still patchy, so keep a POST fallback for now

Full article with more details: https://devencyclopedia.com/blog/http-query-method-express-nodejs

Git Worktrees for Parallel AI Coding Agents: The Complete 2026 Workflow

Dev Encyclopedia — Tue, 07 Jul 2026 03:02:27 +0000

The Problem With Running Multiple AI Agents on One Checkout

If you've tried running two AI coding agents (or juggling two features yourself) in the same git checkout, you've probably hit this:

File edits get overwritten between sessions
package.json and lockfiles get corrupted from simultaneous writes
Agent context gets polluted with half-finished, unrelated changes
You end up working sequentially instead of in parallel, which defeats the whole point

There's a git feature built for exactly this, and it's been around since git 2.5 (2015): worktrees.

What Are Git Worktrees?

A worktree lets you check out multiple branches from the same repository into separate directories at the same time.

One shared .git history and object database
Multiple independent working directories, each on its own branch
No duplication of git internals, only the checked-out files

git worktree add ../app-auth feature/auth
git worktree add ../app-api feature/api

Now you have two fully independent folders, each with its own files, its own node_modules, and its own staging area, both pointing at the same repo history.

Why This Matters for AI Coding Agents

Point one Claude Code (or any AI agent) session at each worktree folder, and they run completely in parallel with zero collisions. No stashing, no branch-switching dance, no waiting your turn.

Claude Code even ships a native --worktree flag that auto-generates the branch name and directory setup for you in a single command.

What's Covered in the Full Guide

Step-by-step worktree setup and teardown
Common errors: stale locks, missing .env files, "branch already checked out"
A clear framework for when worktrees are worth the overhead and when they're not
Practical integration with AI coding agent workflows

👉 Read the full breakdown here: https://devencyclopedia.com/blog/git-worktrees-parallel-ai-coding-agents

If you're running multi-agent AI coding setups, this is foundational infrastructure worth understanding properly.

Stop Guessing Which Temporal Type to Use: A Free Interactive Picker

Dev Encyclopedia — Mon, 06 Jul 2026 03:23:06 +0000

JavaScript's Temporal API gives you six different types for representing dates and times: Instant, ZonedDateTime, PlainDate, PlainDateTime, PlainTime, and PlainYearMonth. Picking the wrong one is an easy mistake, and it usually shows up later as a timezone bug, a DST edge case, or data that silently loses precision.

The problem

Most guides explain what each Temporal type is, but not which one you should actually use for your specific field. Should a "created at" timestamp be an Instant or a ZonedDateTime? What about a user's birthday? A recurring meeting time?

The fix

I built a small interactive tool called the Temporal Type Picker to answer this in two quick questions:

What are you modeling? (a point in time, a calendar date, a wall-clock time, or a duration)
Does timezone information matter for your use case?

Based on your answers, it gives you:

The exact Temporal type to use
Ready-to-copy constructor code
The matching PostgreSQL column type for your schema

It's fully client-side, no signup, no data collection, and works entirely in your browser.

🔗 Try it here: Temporal Type Picker

If you're working with dates in modern JavaScript or designing a schema that touches timestamps, this should save you a debugging session or two.

Claude Fable 5: What It Is and When to Use It

Dev Encyclopedia — Sun, 05 Jul 2026 04:35:52 +0000

Anthropic just released Claude Fable 5, the first public model from its new Mythos tier. If you're picking between this and Opus 4.8 for your next project, here's what actually matters.

What Makes It Different

Claude Fable 5 is built for long-horizon agentic work: multi-day coding sessions, large-scale migrations, and workflows that need to plan, execute, and self-verify without constant hand-holding.

1M token context window
Up to 128K output tokens
Always-on adaptive thinking
Its performance edge over Opus 4.8 grows as task complexity increases. On quick, simple tasks the gap is small. On multi-step agentic workflows, it's significant.

The Safety Fallback You Should Know About

Sensitive queries touching cybersecurity, biology, or chemistry automatically reroute to Opus 4.8, and are billed at Opus rates, not Fable 5 rates. Worth knowing before you budget a project around it.

Is It Worth the Cost?

Fable 5 costs roughly 2x Opus 4.8 per token. But token cost isn't the number that matters, cost per completed task is.

If Fable 5 nails a hard job on the first attempt where a cheaper model needs two or three retries to get there, it can end up cheaper overall, not more expensive.

When to Use Which

Use Case	Recommended Model
Quick edits, simple scripts	Opus 4.8
Multi-day agentic coding tasks	Fable 5
Large-scale refactors/migrations	Fable 5
Cyber/bio/chem-sensitive queries	Auto-routes to Opus 4.8

Full breakdown with benchmarks, pricing tables, and a complete decision framework in the original post:

🔗 Read the full guide:
https://devencyclopedia.com/blog/claude-fable-5-guide

What's been your experience with Fable 5 so far? Drop a comment below.

How to Use Environment Variables in Next.js (Without Leaking Them to the Browser)

Dev Encyclopedia — Sat, 04 Jul 2026 03:47:16 +0000

If you've worked with Next.js for a while, you've probably run into this at least once: an environment variable that works perfectly on your machine, then either goes missing after deploy or, worse, shows up in the browser where anyone can see it.

The core rule

Next.js splits environment variables into two groups:

Server only (default): plain names like DATABASE_URL or API_SECRET_KEY. These never reach the browser.
Public: any variable prefixed with NEXT_PUBLIC_. These get bundled into your client JavaScript and are visible to anyone using DevTools.

Mixing these up is how secrets end up exposed.

What the full guide covers

In the complete post, I break down:

How Next.js loads .env, .env.local, .env.production, and friends, and in what order
Build time vs runtime variables, and why this distinction trips people up in Docker and Cloudflare setups
How to validate your environment variables so a missing one fails your build instead of crashing in production
Correct setup for Vercel, Cloudflare, and Docker deployments
Sneaky mistakes, like destructuring process.env, that silently break variable access

👉 Full guide here: https://devencyclopedia.com/blog/nextjs-environment-variables

Have you ever shipped a secret to the browser by mistake? Drop your story in the comments, happy to compare notes.

45 OOP Interview Questions and Answers (2026)

Dev Encyclopedia — Fri, 03 Jul 2026 03:28:57 +0000

Preparing for an OOP interview in 2026? I put together a guide covering 45 questions that actually come up, from the four pillars all the way to SOLID principles and design patterns.

What's inside

The four pillars explained with real code, not just definitions
Encapsulation vs Abstraction, the pair almost everyone mixes up
Method Overloading vs Overriding
All 5 SOLID principles, each with a violation and a fix
8 design patterns interviewers actually ask about (Singleton, Factory, Observer, Strategy, Decorator, Adapter, and more)
A full parking lot system design walkthrough
Java, Python, JavaScript, and C# quirks compared side by side

Whether you're prepping for a frontend, backend, or full stack interview, OOP fundamentals show up everywhere. This guide is built to be skimmed fast and used as an actual reference, not just read once and forgotten.

Full guide here: https://devencyclopedia.com/blog/oop-interview-questions

What OOP interview question trips you up the most? Drop it in the comments.

Next.js middleware.ts to proxy.ts: What Changes and Why It Matters

Dev Encyclopedia — Thu, 02 Jul 2026 04:13:26 +0000

Next.js 16 quietly renamed middleware.ts to proxy.ts. Most changelogs bury it next to Cache Components and Turbopack updates, but it deserves its own conversation.

What Actually Changes

Filename: middleware.ts becomes proxy.ts
Export: named export middleware becomes default export proxy
Default runtime: Edge becomes Node.js

That third point is the one worth sitting with. Edge runtime gave you global low latency distribution but a restricted API surface, so you were often stuck finding Edge compatible forks of packages or writing workarounds. Node.js runtime removes most of that friction since proxy.ts now has full Node API access by default.

Do You Need to Migrate Right Now?

middleware.ts still works. It's deprecated, not removed, so nothing breaks on upgrade.

If your middleware just checks cookies, headers, or does basic redirects: migrate now, it's roughly a five minute rename and retest.
If you're leaning on Edge specific geo distribution or Edge only APIs: branch it, benchmark proxy.ts under real traffic patterns first, then decide.

What's in the Full Guide

The full writeup covers a real auth check example migrated step by step, a compatibility table for what breaks (and what doesn't) under the Node.js runtime, and a free tool that rewrites your middleware file for you automatically.

Read the full guide: https://devencyclopedia.com/blog/nextjs-middleware-to-proxy

Curious what others are seeing here, has anyone hit compatibility issues moving from Edge to Node.js runtime in production?

50 DSA Interview Questions and Answers (2026)

Dev Encyclopedia — Wed, 01 Jul 2026 02:45:44 +0000

Most developers memorize 300+ coding problems before interviews.

The ones who actually get hired? They learn 8 patterns that cover 90% of everything.

I just published a complete DSA interview prep guide with 50 questions and answers — and the most important part isn't the solutions. It's the patterns behind them.

Here's what I mean:

The "Two Pointers" pattern solves sorted array problems.
The "Sliding Window" pattern solves substring/subarray problems.
The "Fast & Slow Pointers" pattern finds cycles AND middle elements.
The "Backtracking" pattern generates all combinations or permutations.

One pattern. Multiple problems. That's the difference between grinding and actually understanding.

The guide covers:

Big-O notation and why interviewers care about it
Arrays, Linked Lists, Stacks, and Queues with real code
Trees and Graphs (including the classic "Number of Islands")
8 coding patterns that map to most interview problems
Dynamic Programming broken down simply (starting with Climbing Stairs)
The most common mistakes candidates make (and how to avoid them)

Quick example: Two Sum in O(n)

def two_sum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    return []

No nested loops. Just one hash map and a single pass. That's what learning patterns looks like.

If Dynamic Programming always felt impossible, start with Q42 in the guide. It clicks when you see it as just Fibonacci with a twist.

👉 Full guide (free, no login needed): 50 DSA Interview Questions and Answers

Save this for your next interview prep session.

dsa #interviews #programming #algorithms #python #javascript #webdev #career

Your App Crashed. The Log Says '137'. What Does That Even Mean?

Dev Encyclopedia — Tue, 30 Jun 2026 02:08:14 +0000

Imagine this.

It is 3 AM. Your app is down. Your phone is buzzing. And the only clue you have is this:

Exit Code: 137

No explanation. No hint. Just a number staring back at you.

This happens to developers every single day. And every time, the process is the same:

Google the error code
Land on a 5,000 word documentation page
Read half of it
Still not sure what caused it
Try something random
Hope it works

That whole process can take 30 minutes or more. For a number. For one number.

So what does 137 actually mean?

It means your app ran out of memory.

The system gave your application a memory limit. Your app crossed it. The system force-killed it immediately. No warning. No graceful shutdown. Just gone.

That is it. That is the whole explanation.

But finding that answer used to require knowing:

What "exit codes" are
What "SIGKILL" means
What "OOMKilled" stands for
How to run the right terminal command to confirm it

Most developers know this eventually. But when you are half asleep at 3 AM staring at a number, you just want a straight answer.

I built a tool that gives you that straight answer

It is called Exit Code Lookup and it lives on devEncyclopedia.com.

Here is how it works:

Step 1: Type the error code, signal name, or status you see in your logs

Step 2: Get a plain-English explanation of what it means

Step 3: Get the exact command to confirm and fix it

That is the whole tool. No signup. No reading. Just paste the code and get the answer.

Some examples of what it decodes

What you type	What it means (plain English)
`137`	App ran out of memory and was force-killed
`143`	App was shut down cleanly during a deployment update
`127`	The app file could not be found inside the container
`1`	Something went wrong inside the app itself
`CrashLoopBackOff`	App keeps crashing and restarting in a loop
`OOMKilled`	Out of memory, same root cause as exit code 137
`ImagePullBackOff`	Cannot download the app package to run it
`SIGTERM`	A graceful shutdown signal, usually nothing to worry about

Why this matters even if you are not a developer

If you manage a team that builds software, or you work alongside developers, you will hear these terms. Now you know what they mean.

If you are a developer just starting out, bookmarking this tool will save you real time on real incidents.

If you are experienced, you already know how annoying it is to look these up mid-incident. Having them in one place with diagnostic commands ready to copy is just faster.

Try it yourself

Go to: https://devencyclopedia.com/tools/exit-code-lookup

Type 137 and see what comes back.

Then try CrashLoopBackOff.

The whole point of the tool is that you should understand the result even if you have never touched a server in your life.

Free. No account needed. Works in your browser.

Built by the team at devEncyclopedia.com, a reference site for developers that believes documentation should be readable by humans.

Bun 1.3's Built-in SQL and Redis Clients: Do You Still Need pg, mysql2, and ioredis?

Dev Encyclopedia — Sun, 28 Jun 2026 23:47:34 +0000

Bun 1.3 shipped something no other JavaScript runtime has attempted: built-in clients for PostgreSQL, MySQL, SQLite, and Redis. Zero npm dependencies, zero native bindings, zero config files. You write Bun.sql or Bun.redis and it works.

If you've been running pg, mysql2, and ioredis for years, the real question isn't whether this is cool, it's whether these built-ins are actually ready to replace your existing setup.

What changes with Bun.SQL

vs pg (PostgreSQL)

No more manual .connect(), no more .rows unwrapping, and transactions collapse into a single call:

await sql.begin(async (tx) => {
  await tx`UPDATE accounts SET balance = balance - ${amount} WHERE id = ${fromAccount}`;
  await tx`UPDATE accounts SET balance = balance + ${amount} WHERE id = ${toAccount}`;
});
// Auto-commits on success, auto-rolls back on exception

vs mysql2 (MySQL)

The same tagged template syntax works for both Postgres and MySQL. Switch databases and your query code doesn't change, only the connection config does.

vs ioredis

Options objects replace positional flag strings:

// ioredis
await redis.set(key, val, 'EX', 60, 'NX');

// Bun.redis
await redis.set(key, val, { ex: 60, nx: true });

Pub/sub moves from event emitters to async iterators, which fits more naturally with for await...of.

The honest performance take

Bun's own benchmarks claim up to 7.9x throughput over ioredis. In synthetic tight-loop tests, sure. In a real app with network latency and business logic between calls, expect something closer to 10 to 30 percent improvement. Real, but not a reason to migrate on its own.

What's actually missing

No Redis Cluster support yet
No Lua scripting on Bun.redis
No Sentinel support
MySQL mode lacks prepared statement caching
If you need to run on Node.js too, the npm packages remain your only option

Should you migrate now?

If you're starting fresh on Bun with simple CRUD and basic Redis usage, probably yes. If you depend on Redis Cluster, Lua scripts, or an ORM without Bun.SQL adapter support (Prisma and TypeORM don't have one yet), wait.

Full side-by-side code comparisons, a complete migration decision framework, and a dev/prod database-switching pattern are in the full post:

🔗 https://devencyclopedia.com/blog/bun-sql-redis-clients

If you want to convert your existing pg/mysql2/ioredis code automatically, I also built a Bun Snippet Converter that runs entirely client-side.