DEV Community: curioustore

Vercel AI SDK 6: An Agent Is Just a while Loop

curioustore — Fri, 10 Jul 2026 14:38:28 +0000

I wired the same model and the same single tool into two functions in the exact same way. One of them ran the tool once and then gave back no answer at all; the other called that same model twenty times over. The only thing that changed in the code was one line — whether or not I flipped on an option called stopWhen.

That was the scene I ran into the first time I actually installed Vercel AI SDK 6 and ran something on top of ai@6.0.212. These days the library leads with the banner of an "agent framework." Yet what that word "agent" points to at the level of real code turns out to be surprisingly fuzzy. So this post strips away the marketing copy and takes apart, by hand, what the AI SDK 6 agent actually is as a control flow — with no model API key, no GPU, and not a single external call.

[!NOTE]
Every number and behavior in this post was verified by running it myself against a mock model on Windows 11 · Node v24.15.0 · ai@6.0.212 · zod@4.4.3. Because no real LLM is ever called, the results reproduce identically every time. Why the "mock model" is the crux is something I explain separately halfway through.

What does the AI SDK actually do for you

Let me lay the groundwork before the main event, so that even a first-time reader can follow all the way through.

In web development, when we send an HTTP request to a server, we don't hand-write the low-level, browser-specific code ourselves. An abstraction layer like fetch or axios papers over the differences. The AI SDK is fetch for calling LLMs (large language models). It wraps the vendor-by-vendor APIs — OpenAI, Anthropic, Google — behind a single function like generateText, so you can swap models like changing a plug in a socket while your app code stays put. Think of it as an adapter that turns every vendor's differently shaped plug into one power strip.

As of 2026, AI SDK 6 has moved up to a general availability (GA) release (not a beta), and the ai@6.0.x package is still being updated as of late June. Four things stand out as the headline changes from 5 to 6.

ToolLoopAgent — the official API that bundles "the agent" into a single class (the protagonist of this post).
Human-in-the-loop tool approval — a mechanism that inserts a human check before a risky tool call.
Stabilized structured output — forcing a model's response into an object of a fixed shape rather than free text.
DevTools — a debugging tool for inspecting which steps an agent took.

Let me unpack just two terms first. A tool call is the model asking, "instead of answering directly, please call the getWeather('Seoul') function for me." The model can't run functions itself, so our code does the running and hands the result back to the model. An agent is exactly this round trip — model calls a tool → we run it and return the result → the model looks at that and decides what's next — repeated until the job is done. It sounds grand, but as we'll see shortly, the reality of it is one ordinary loop.

What an "agent" really is: the while loop that stopWhen turns on

The first thing I wanted to confirm was this: if you hand tools to generateText, does that by itself make it an agent?

I scripted the mock model to move along like this. On step 1 it returns a tool call saying "call the weather tool with {city:'Seoul'}," and on step 2 it returns the final text "Seoul is 21C." Then I called that same model two different ways.

First, plainly, with no options — generateText({ model, tools, prompt }):

Observation	Value
Step count	1
Model calls (`doGenerate`)	1
Final text	"" (empty string)
Did the tool run?	Yes — `{city:'Seoul', tempC:21}`

The tool clearly ran. And yet the final answer is empty. Why? Because the model called the tool once and stopped right there. The tool's result never went back to the model, and the model never got a second turn. By default, generateText is a one-shot function that ends the moment a tool is called once. The automatic round trip we casually call "an agent" simply isn't here.

Now I added a single line — stopWhen: stepCountIs(5):

Observation	Value
Step count	2
Model calls	2
Final text	"Seoul is 21C."

Same model, same tool — but this time the model was called twice. When the first call requested the tool, the SDK ran it, appended the result to the conversation, and called the model again; on that second call the model finally produced its closing sentence. That is exactly the contradictory scene from the opening.

stopWhen, true to its name, is the condition that decides when to stop. stepCountIs(5) means "run for at most 5 steps," hasToolCall('weather') means "stop the moment that tool is called," and you can supply your own function for a custom condition too. Sure enough, when I set hasToolCall('weather'), it stopped at exactly step 1, right after the tool was called.

So in AI SDK 6, what an "agent" really is is a while loop that keeps calling the model until stopWhen says stop. Not magic — a loop with a termination condition, and the switch that turns that termination condition on is stopWhen.

Diagram: this section is illustrated with a flowchart — view it in the original article on var.gg.

This is where a class called ToolLoopAgent comes in. Its official name is ToolLoopAgent (the older beta's Experimental_Agent remains as an alias pointing at the same class — in my install, ToolLoopAgent === Experimental_Agent was true), and what it does is bundle the model, tools, and stopWhen into one object: a thin wrapper. Its internal loop is identical to the one we just saw in generateText.

There is one decisive difference, though. Even if you don't give ToolLoopAgent a stopWhen, it ships with stepCountIs(20) as the default. I fed a mock model that endlessly re-requests the tool into both approaches.

Call style	Step count with no stopWhen
`generateText`	1 (no loop)
`ToolLoopAgent`	20 (stops at the default cap)

Same model, but one runs once and the other twenty times. That number 20 is the whole identity of "the agent." generateText starts out with its loop switched off, and ToolLoopAgent starts out with its loop switched on at 20 steps. That is the entirety of the essential difference between the two APIs.

[!WARNING]
So here's the first real-world trap. If the model, for whatever reason, never stops calling tools, ToolLoopAgent will quietly call the model 20 times — meaning you're billed 20 times. It saves you from an infinite loop, but that ceiling is also your cost ceiling. stopWhen is both a safety catch and a budget dial.

When the loop hits an error: it doesn't die, it snitches to the model

Tools don't always succeed cleanly. So I broke one on purpose. I built a tool whose execute() immediately does throw new Error('TOOL_BOOM') and dropped it into the loop. My expectation was "the loop blows up on the exception and dies."

Wrong. The loop did not throw. Instead it went like this:

That step's content was recorded as two pieces, ["tool-call", "tool-error"],
that tool-error was fed back to the model in place of a tool result, and
on the next step the model saw the error and tried to recover with the text "recovered."

The same held when the model called a tool that doesn't even exist. Instead of a crash, it surfaced as a tool-error and the loop carried on. In other words, AI SDK 6 is designed to catch tool-execution failures by default and, rather than throwing an exception, tell the model "this tool failed in this way." It's a self-heal structure that leaves the model room to route around the failure or pick a different tool on its own.

This isn't all upside. Because the error is quietly absorbed into the conversation, those of us outside the code may only notice later — "the tool failed, so why did I just pay more?" This automatic feedback is the default behavior, and using it while knowing you can change it (via tool options or an error handler) is different from using it unaware. It rhymes with cooperative cancellation in general: when you abort a request midway, what actually stops and what keeps spinning on as "orphan work" always comes down to someone's cooperation — control is never something you hold unilaterally.

The type boundary of structured output: compile time and runtime are different layers

The next thing I looked at was structured output. A model, left to itself, spits out free text. But an app often needs an object of a fixed shape like { city: string, tempC: number }. For this, the AI SDK provides — separate from the free-text generateText — a path that forces the result to conform to a schema. The dedicated function generateObject shows the boundary most sharply, so I experimented with it, but one thing is worth flagging up front: in v6, generateObject is already marked @deprecated. The installed type definitions themselves steer you to "use the output setting on generateText instead." For new code, generateText({ output: Output.object({ schema }) }) is the recommended path (though this result still comes out under the name experimental_output — i.e., the surface isn't fully set yet). Either way, the type-versus-validation boundary is the same, so I'll show the experiment below with generateObject, where that boundary is crispest.

I gave it the zod (a runtime schema-validation library) schema z.object({ city: z.string(), tempC: z.number() }) and ran three cases.

What the model emitted	`generateObject` result
`{"city":"Seoul","tempC":21}`	Valid — typed object. At runtime `object.tempC * 2 = 42` works
`{"city":"Seoul","tempC":"hot"}` (type violation)	`AI_NoObjectGeneratedError` thrown
`totally not json`	`AI_NoObjectGeneratedError` thrown

Let me clear up a common misconception here. "Give it a TypeScript type and the model will honor that type" is a half-truth. The type is a compile-time promise, and whether the model actually kept that promise is checked by zod at runtime. They're different layers. The compiler guarantees the type, but the model can break the promise at runtime however it likes, and when it does the SDK throws an exception rather than quietly forcing a fit.

The type layer itself is solid. Checking with a separate type pass (tsc --strict), generateText's result .text is string (no structure at all), while generateObject({ schema })'s .object.tempC was a number inferred from the schema. Trying to assign a string where a number belongs produced a compile error. What the compiler catches is "does my code use the object correctly," and what zod catches is "did the model produce a correct object." Mistake the two for the same thing and you'll get the experience where the types pass but production blows up with a NoObjectGeneratedError.

Streaming is a procession of typed parts

When you stream a response with streamText, characters trickle onto the screen — but what's happening underneath? With a mock model I built a stream mixing text fragments and tool calls, and transcribed the order of the pieces that land on fullStream exactly as they came.

start → start-step → text-start → text-delta → text-end
  → tool-input-start → tool-input-delta → tool-input-end
  → tool-call → tool-result → finish-step → finish

Two things matter here. First, a stream is not a blob of characters but a sequence of typed events — text-start, text-delta, text-end; tool-input start, delta, end — each stage split into its own part, so the UI can render exactly whether "the model is calling a tool right now" or "is writing text." Second, tool-result shows up in the middle of the stream, right after tool-call. That means the SDK doesn't wait for streaming to finish before running the tool; it runs the tool mid-flow and splices the result back into the stream.

The quiet v5 → v6 trap: the vanished maxSteps

One note for anyone considering a migration. In AI SDK 5, the option that turned on the multi-step loop was maxSteps. In v6 this option was removed. The problem is that it disappears without making any noise.

I passed generateText({ ..., maxSteps: 5 }) through just like v5 code. Type checking did flag that maxSteps is no longer a valid option (confirmed with @ts-expect-error), but at runtime it was silently ignored — step count 1, one model call, final text an empty string. In other words, an agent loop that ran fine on maxSteps in v5 will, in any environment that skips type checking (pure JS, a loose build), degrade into a one-shot function without a single line of error the moment you bump to v6, and the answer goes empty. In v6 you have to turn the loop on with stopWhen.

[!NOTE]
To sum up, there are two ways to turn on multi-step in v6 — the functional way gives stopWhen directly to generateText/streamText, and the object way uses ToolLoopAgent and decides whether to keep or lower the default stepCountIs(20). The v5 maxSteps and system parameters were renamed to stopWhen and instructions, respectively.

What it gives you, and what it doesn't

After running it myself, the most honest thing I can say is that AI SDK 6's boundary between what it gives you and what it doesn't is sharper than you'd expect.

What it gives

Provider abstraction — swap model vendors and your app code stays almost the same.
A type-safe surface — tool inputs/outputs and structured output are bound on both sides, by TypeScript types and zod runtime validation.
A standardized stream — typed parts let the UI draw each stage precisely.
Testability — with the mock model I'll cover separately below, you can reproduce the entire control flow deterministically, no model required.

What it doesn't give

The agent's reliability. It provides the loop, but there's no guarantee the model calls the right tool the right way. Preventing an infinite loop is on you, via stopWhen.
Rollback of side effects. If a tool wrote to the outside world, halting the loop doesn't undo it. Cancellation is not rollback.
Complete concealment of provider differences. Native support for structured output and the streaming details vary by real model, and a mock model won't show you those differences.

This last item matters. Every conclusion in this post is the "contract and control flow" seen on top of a mock model — it does not reproduce a real LLM's caprice (nonsensical tool arguments, an unquenchable appetite for calling tools). The mock model clearly shows one half of the truth — how the SDK promised to behave — and the other half (how the model breaks that promise) only surfaces with a real provider.

But why is the "mock model" the crux?

A mock model is a model implementation whose script we write in ourselves, in place of a real LLM. AI SDK 6 officially ships MockLanguageModelV3 in ai/test. Because you can nail down in code "return this tool call as the response, then return this text next," you can reproduce the agent loop, the stop condition, error handling, and streaming order in full — with no API key, no cost, and no network. This is exactly why this post could fill in every table above while calling the model zero times.

Plenty of "build a chatbot with the AI SDK" posts are out there, but ones that tackle "how to test AI features deterministically, at zero cost" head-on are rare. From a product-code standpoint the latter is actually the more urgent need, because you can't validate the loop and failure paths of an agent bound for production against a real model that burns money and wobbles on every run. Set this next to how the Python world pins an agent's inputs and outputs down with types to solve the same problem, and the contrast gets sharp.

Measured against the alternatives

The AI SDK isn't the only road to building an agent. Here's how it shakes out, based on hands-on experience and each tool's official positioning.

Option	Abstraction level	Type safety	Testability	Lock-in risk
AI SDK 6	Medium — provider abstraction + loop	High (TS + zod)	High (official mock model)	Low (multi-provider)
LangChain.js	High — up to chains/graphs	Medium	Medium	Medium (heavy ecosystem dependence)
Mastra	High — workflow-centric	High (TS-first)	Medium	Medium
OpenAI Agents SDK (JS)	Medium — agent-specialized	Medium	Medium	High (OpenAI-flavored)
Raw fetch	None	By hand	By hand	None

The point isn't "which is best." AI SDK 6's place is the spot that keeps the abstraction thin (only as far as the loop and the provider) while keeping types and testing solid. If you need higher-level orchestration (complex branching, long-running workflows), LangChain or Mastra may fit better; if you're fine binding deeply to one provider, that vendor's SDK might. The AI SDK's strength isn't a flashy graph — it's that, just as we did a moment ago, you can inspect every corner of the loop without a model.

When to reach for it, and what to remember

This tool shines brightest when you want to add "an AI feature with tool calls, in a way that's less bound to a provider and solid on types and testing." Conversely, if complex long-running workflow orchestration is the essence of what you're building, look to a heavier framework. After taking it apart myself, the sentences that stick are just a few.

An agent isn't magic; it's a while loop that stopWhen turns on. generateText starts with the loop off, ToolLoopAgent with it on at a default of 20 steps.
Every step of the loop is a cost. stopWhen is both a safety catch and a budget dial.
Tool failures don't blow up by default; they're fed back to the model. Self-healing is convenient, but it can become a silent cost.
Types (compile time) and validation (runtime) are different layers. generateObject answers a promise-breaking model with an exception.
maxSteps is gone in v6. It can quietly degrade into a one-shot function during migration, so move it over to stopWhen.

In an era where "agents write the code," using an agent without knowing what loop it actually is on the inside is precarious. (I reached the same conclusion writing about git tooling in the agent era — the smarter an abstraction gets, the more you owe it to yourself to run the thing underneath at least once and see what actually turns.) The AI SDK 6 "agent," fortunately, was open enough to inspect all the way through without calling a model even once.

Originally published at var.gg.

uv audit vs pip-audit, and a gate narrower than it looks

curioustore — Fri, 10 Jul 2026 14:38:23 +0000

Until now, the tools that install packages have never once stopped to ask, "Are you sure it's okay to take this one?" Whether it's pip install or npm install, they've been faithful delivery drivers: they read the name and version on the invoice, fetch exactly that item, and set it on your doorstep. Whether the item was recalled days ago, or is a counterfeit someone swapped in under the same name, was never the driver's concern.

This faithfulness is usually a virtue, but it carries one uncomfortable trait. A lockfile — a file that pins the exact versions and dependency graph of what you'll install, uv.lock being the canonical example — exists for the sake of reproducibility. The version you picked six months ago installs today, and on a colleague's machine too, identically, down to the last bit. But what if that choice six months ago was a bad one? A lockfile faithfully reproduces even a dangerous past decision. Even for a package that was pulled from PyPI after a problem surfaced, if your lockfile already knows where that file lives, the install path quietly stays open.

uv, the Python package manager built by Astral, started in 2026 to hand this faithful delivery driver a new role for the first time: the role of an inspector who pauses just before installing to say, "Hold on — this item is on a list." On June 8, Astral unveiled uv audit (a dependency vulnerability scanner) and a malicious-package check that runs at install time. Both are still preview (experimental, subject to change at any time).

I didn't just read about this. I pulled the latest uv, built a throwaway project deliberately stuffed with vulnerable packages, and ran uv audit side by side with the long-standing standard tool pip-audit against the same lockfile, measuring speed and results myself. I also cracked open the binary to see where the malicious-package gate actually fires. Along the way I hit a few places where the official blog's wording didn't quite match what I saw, and a security boundary far narrower than I'd expected. Let me walk through it.

The uv version used in this article is 0.11.23 (released 2026-06-19). Every measurement was done on a single Windows machine, in an isolated throwaway project that never touched any production environment.

First, let's separate two features that look alike

When you first see the announcement, it's easy to read it as a vague "uv added a security feature." But what actually landed is two things of a different nature, and conflating them makes the whole story confusing.

uv audit — a scanner that checks the package names and versions in your lockfile against records of already-known vulnerabilities. It doesn't block anything. It simply reports "there are N known problems among these" and stops there.
UV_MALWARE_CHECK — a gate that, just before uv sync performs the actual install, aborts the install itself if a known malicious package version is in the mix.

The latter is the one that comes close to a real "security gate." But both share a common limitation. Despite the name, neither analyzes the contents of a package file the way antivirus would. What both actually do is compare your packages against a "list of bad names and versions" already registered in a public database called OSV.

One-line glossary — OSV (Open Source Vulnerabilities): a public database and API that gathers, in a single common format, which version of which package corresponds to which known vulnerability or malicious behavior. It pulls in many sources — Python security advisories, OpenSSF's malicious-package reports, and more. Malicious-package records usually carry an identifier starting with MAL-.

Here's an analogy. This check is not the airport's baggage X-ray. It doesn't open your bag and look inside; it's closer to matching passenger names against a no-fly list at the gate. Anyone on the list gets stopped. But a new threat not yet on the list, a forged ID no one has seen before, simply walks through. Keep this analogy in mind and the "things this does not block," coming later, will make natural sense.

Running `uv audit` myself

Running it once is faster than describing it in words. I built a throwaway project deliberately filled with old, vulnerable versions.

[project]
name = "audit-fixture"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
    "requests==2.19.1",
    "jinja2==2.10",
    "pyyaml==5.3",
    "flask==0.12.2",
]

Running uv lock pinned it to 14 packages counting direct and indirect dependencies (including transitive dependencies — the ones I didn't list myself but another package dragged in, like urllib3 pulled in by requests or werkzeug pulled in by flask). Then I ran the audit on top of that.

$ uv audit
warning: `uv audit` is experimental and may change without warning.
         Pass `--preview-features audit-command` to disable this warning.
Found 48 known vulnerabilities and no adverse project statuses in 13 packages

It's honest from the very first line. Because uv audit is preview, running it plain raises a warning that it's an experimental feature and may change at any time. Adding --preview-features audit-command only makes the warning go away; the feature behaves exactly the same. In other words, this flag isn't a "switch that turns the feature on" but a stamp that confirms "I know this is experimental."

The result: 48 known vulnerabilities across 13 packages. The human-readable text output breaks the vulnerabilities out package by package.

flask 0.12.2 has 7 known vulnerabilities:

- GHSA-562c-5r94-xh97: Flask is vulnerable to Denial of Service ...
  Fixed in: 0.12.3
  Advisory information: https://nvd.nist.gov/vuln/detail/CVE-2018-1000656
...

One-line glossary — CVE / GHSA: both are identifiers attached to a vulnerability. A CVE is a number many organizations use in common; a GHSA is a number GitHub assigns. The same incident can hold both numbers at once, and that fact becomes important later when comparing tools.

Not for humans — machine-readable output

Up to here, it's just a prettier pip-audit. The place uv audit is really aiming for is the CI (continuous integration) pipeline. That's why there are three output formats.

Format	Purpose	What I verified
`text`	reading in a terminal	the default
`json`	post-processing / policy scripts	`schema` (version=preview), `summary`, `vulnerabilities[]`, `adverse_statuses` keys
`sarif`	upload to GitHub Code Scanning	SARIF 2.1.0, tool name `uv` 0.11.23, 48 rules and 48 results

One-line glossary — SARIF: a JSON specification for uploading static-analysis results to systems like GitHub in a standard format. With it, audit results show up automatically in a PR's "Security" tab. SARIF output was only added on June 18 in uv 0.11.22 — a version from a month earlier doesn't have it.

The exit code is CI-friendly too. It returns 1 if there's even one vulnerability and 0 if things are clean. So a single line of uv audit, with no extra script, can turn CI red. When I switched to a clean project with certifi as the only dependency, it returned exit code 0 as expected.

Silencing the noise, and the trap in it

Not every known vulnerability is "a risk to us right now." So --ignore lets you hide a specific advisory. What was interesting was the matching behavior. Passing a single --ignore GHSA-562c-5r94-xh97 dropped the count from 48 to 46 — two entries disappeared. That's because the alias records (CVE, PYSEC) tied to that GHSA were suppressed along with it. It means an ID is matched inclusive of its aliases.

There's an operational trap here. --ignore-until-fixed sounds reasonable — "hide it only until a fixed version ships" — but if a fixed version never ships, it stays hidden forever. It's not an expiry like "grant a pass for 30 days." So in practice it's safer to manage the ignore list separately, outside uv's configuration — who granted the pass, why, until when, and under which ticket.

# minimal form of an ignore policy that should live outside uv
id: GHSA-xxxx-yyyy-zzzz
owner: platform-security
reason: vulnerable code path is never actually invoked
expires: 2026-07-20
ticket: SEC-1234

Side by side with `pip-audit`: same answer, different speed

Now the real question. How is this different from pip-audit, the long-standing standard? I exported the same lockfile to requirements.txt, then ran both tools aligned to the same OSV data source.

Results first. I took the vulnerabilities each tool found, expanded them into sets down to their aliases, and compared.

uv audit     : unique IDs (aliases included) 79
pip-audit    : unique IDs (aliases included) 79
intersection : 79  (symmetric difference 0)

They were completely identical. Even the distribution by type matched (PYSEC 18, CVE 30, GHSA 30, SNYK 1). The set of vulnerable packages was the same too. Which is also the expected result — both look at the same OSV. That's the first key point.

[!NOTE]
The value of uv audit is not that it "finds more vulnerabilities." If it looks at the same data, it finds the same things. The real difference is (1) speed, (2) native SARIF/JSON output, and (3) that it's integrated with the lockfile and resolver inside a single tool.

So what about speed? Here are the results, measured with the tools' caches warmed up.

Tool	cold (first run)	warm (median)
`uv audit`	~2.2s	~0.8s
`pip-audit` (OSV)	22.7s*	~16s

* pip-audit's cold run includes the time to install the tool itself.

It felt like more than a 20x difference. But I have to be honest here. This is not a well-controlled benchmark. I let my pip-audit runs re-resolve dependencies every time (skipping optimizations like --no-deps), while I let uv use the lockfile as-is. The number Astral officially cites is "4–10x," and in the same blog post they add their own caveat that the gap can shrink substantially once pip-audit's cache and resolution are sufficiently warm. My measurement can only say "uv is clearly faster"; the "exactly how many times" is a number my measurement conditions produced.

That's a lesson in itself. A benchmark can be inflated in any direction if you're inclined to. To trust a comparison you have to align the same data source, the same input scope, the same cache state — an "Nx faster" that doesn't is just a headline. (When I benchmarked the TypeScript 7 native compiler myself on this blog, the official "10x" turned out to be 3x on our code. A headline multiplier is always a number that came out of someone's particular codebase.)

The side that blocks installs: the malicious-package gate

uv audit only reports. Actually blocking an install is a separate feature. And here I ran into a point that diverges from the official guidance.

First, this gate attaches to uv sync (the install path), not to uv audit. To confirm how it's enabled, I dug through the strings in the uv 0.11.23 binary directly, and this came out.

Malware detected in one or more dependencies that would be installed;
aborting sync. Set `UV_MALWARE_CHECK=0` to bypass this check.

Malware checks are experimental and may change without warning.
Pass `--preview-features malware-check` to disable this warning.

Those two messages say a lot. Setting UV_MALWARE_CHECK=1 on an empty venv and running uv sync did raise the experimental-feature warning above, and the check ran. In other words, the activation switch is the environment variable UV_MALWARE_CHECK=1, and the --preview-features malware-check flag is merely a stamp that turns off the warning. It is not "you must turn on the preview flag to turn on the check." This distinction may look trivial, but it's exactly what you need to know when debugging "why isn't the check running" or "why did it suddenly start running" in CI.

The packages in my throwaway project were merely old, not known malicious packages, so the gate quietly let them through and installed all 13 normally. How it blocks when something is judged malicious, I confirmed from the abort message above and the binary implementation.

[!WARNING]
An honest limitation — I did not force a true positive by actually installing a real malicious package. Pulling known malware onto my own machine isn't safe. I confirmed that the check activates, that the gate sits on the install path, and that a blocking message exists — but I did not reproduce a positive detection itself. Where the article says it "blocks," that's a description grounded in the design and the message, not in a triggered detection.

A boundary narrower than expected

Up to this point it feels reassuring. But once you learn the things this gate does not block, you realize you have to use the phrase "security gate" carefully. The "no-fly list" analogy from earlier earns its keep here.

1. It does not detect yanked files. The adverse status in the "no adverse project statuses" you saw in the uv audit output refers to the project-wide states defined by PEP 792 (archived, deprecated, quarantined). Think of it like a "Closed" or "No Entry" sign on a shop's front door. A yank, by contrast — the mark PyPI attaches to a specific distribution file to say "don't pick this one for new installs," like a "discontinued" sticker slapped on one particular production batch — is per individual file. As of June 2026, uv audit does not report these file-level yanks. The very scenario from the opening — "it was recalled, yet the lockfile keeps pointing at it" — is still a blind spot for this tool.

2. The malicious-package gate only looks at PyPI-sourced packages. In the binary implementation, the malware check queries OSV only for packages in the lockfile that it judges to be from the PyPI registry. So the following currently fall outside the check.

dependencies pinned by direct URL (PEP 508 direct URL)
Git dependencies
local paths and wheel files
private registries
public PyPI packages relayed through a private mirror

The last item is especially dangerous. An organization whose internal mirror simply relays public PyPI is prone to assume "these are PyPI packages, so of course they get checked" — but if the source looks like a mirror, they're skipped.

3. Conversely, the vulnerability lookup casts too wide a net. The vulnerability-lookup side of uv audit sends every auditable name and version to OSV with no source filter. As a result, (1) the names of your internal private packages can leave for an external OSV service, and (2) if such a name collides with an unrelated package on public PyPI, the wrong advisory can match. An organization for which external transmission is a problem should point --service-url or UV_MALWARE_CHECK_URL at an internal proxy.

4. The lockfile is pinned, but the security verdict drifts. This is intended behavior rather than a defect, but in operations it becomes a trap.

same Git commit + same uv.lock
  Monday:  no advisory in OSV       → pass
  Tuesday: new advisory published   → fail

You didn't change a single line of code, yet the build suddenly breaks. So it's better to split the audit into a PR check (does a new dependency bring in new risk?) and a scheduled audit on the default branch (has an advisory published after the fact attached itself to the existing lock?). If you try to catch everything in one place, it gets hard to explain why a PR that was fine yesterday is red today.

Putting these four together into a single picture looks like this.

Diagram: this section is illustrated with a flowchart — view it in the original article on var.gg.

So how does it sit next to other tools

uv audit alone isn't the end of supply-chain security. Here's how to place it.

Tool	Data / input	Malicious packages	CI output	Block point
uv audit + malware check	vulns = OSV, status = index (PEP 792), uses `uv.lock` directly	checks `MAL-` just before install	text, JSON, SARIF	local/CI audit + just before `uv sync`
pip-audit	PyPA advisories by default, OSV optional; requirements / environment / pyproject inputs	official docs state it "is not a malware-defense tool"	columns, JSON, CycloneDX (no native SARIF today)	standalone scanner
Safety	managed vulnerability and malicious data	supports a malicious list	JSON, HTML, SPDX, etc.	CLI scanner (install blocking is a separate product)
Dependabot	GitHub Advisory DB + dependency graph	Python malicious alerts don't apply today (npm-centric)	GitHub UI, PR	after a repo push, at the PR
osv-scanner	OSV; broadly across `uv.lock`, requirements, SBOM, even containers	can detect OSV's `MAL-` as an ordinary finding	JSON, SARIF, CycloneDX	local/CI scanner

Distilled to the essentials: pip-audit is the most direct comparison to uv. osv-scanner reads uv.lock directly and emits SARIF, so it's good as an independent second check. Dependabot is strong for update PRs and long-term maintenance, but it isn't an install gate. And uv's real differentiator isn't a bigger database — it's the position: the tool that knows the dependency graph best has started to hold the decision right at the moment just before the actual install.

So should you turn it on now

Given that these are preview features, here's a realistic order of operations.

Pin uv to a single version (e.g., 0.11.23), and write your parsers loosely, assuming the preview output formats can change at any time.
Start by putting uv audit --frozen into PR checks and scheduled audits. Reporting is safer than blocking.
Rather than forcing the malicious-package gate (UV_MALWARE_CHECK=1) across every developer's machine, turn it on first in the CI and release builders, where it's easy to roll back. Since a failed OSV call currently means the install is blocked (a hard failure), you should first agree on whether "an OSV outage is allowed to block our releases."
To keep uv alone from becoming a single point of failure, run osv-scanner or Dependabot alongside it.

In closing

The significance of uv audit and the malicious-package gate isn't that they invented a new vulnerability database. OSV was already there, and both pip-audit and osv-scanner look at the same place. What changed is the position. The very tool that fetches and installs packages can now, right before fetching, stop and say "this one's on a list."

That pause, though, is still a preview-stage guardrail that blocks "known bad names and versions." It's neither forensics that analyzes a package's contents nor a complete supply-chain defense line. Yanks, direct URLs, private mirrors — all left out. So reading this feature as "uv now protects the supply chain" is dangerous, while reading it as "the install tool has, for the first time, begun to look at the list" is accurate. Turning it on knowing that difference, versus turning it on without knowing it, puts you in an entirely different place when an incident hits.

If you enjoy probing where a supply chain's guarantees actually end, that same lens is worth turning on container signing — cracking open a signature bundle yourself rewards exactly the same skepticism. The gap between what a tool says it "does for you" and what it actually guarantees only ever becomes visible once you've run it yourself.

The measurements in this article are as of June 20, 2026, on uv 0.11.23. Because these are preview features, flags, output, and policy may change in later releases. Official sources: Astral blog, uv release notes, OSV, pip-audit.

Originally published at var.gg.

Vite 8's Rolldown Makes Builds 13x Faster, Not the Dev Server

curioustore — Fri, 10 Jul 2026 14:38:19 +0000

When a new version ships, I usually just type npm install and move on. But installing Vite 8 and looking inside node_modules made me stop for a second. The two names that had always been installed alongside Vite — rollup and esbuild — were gone entirely. In their place sat a single unfamiliar line: rolldown.

That's the heart of Vite 8 (stable release, March 2026). It usually gets summed up as "Vite got faster with Rust," but what actually happened is more specific — and more interesting — than that. For years, Vite ran two separate engines: one for development and another for bundling production builds. Vite 8 merged them into a single Rust bundler called Rolldown. It's less an engine swap than a consolidation — where there used to be two vehicles, now there's one.

Here's the conclusion in one line: the speedup is real, but it lands on the "production build," not the "dev server." What you have to verify in exchange is the real subject of this post. With benchmarks var.gg built firsthand, I'll walk through what changed and what stayed the same.

[!NOTE]
Every measurement here comes from a representative Vite app freshly scaffolded on local Windows (Node v24). var.gg's own frontend runs on Next.js, not Vite, so this isn't a "we migrated our production app" story. Instead it's a reproducible benchmark: the same source tree placed on Vite 7 and Vite 8 in turn, compared on the same machine. So read the numbers as a direction, not a promise — on a large real-world app the multipliers can differ.

So what is Vite, and why did it have two engines?

Let me start by unpacking the unfamiliar terms in plain language, for readers seeing them for the first time.

Bundler: a tool that takes the dozens to thousands of scattered JS, CSS, and image files and packs them so the browser can fetch them quickly, stripping out unnecessary code along the way. Think of it as the person who packs your moving boxes efficiently.
Vite: a tool that wraps that bundler together with the dev server and production build a frontend project needs, all in one package. It's the de facto starting point for React, Vue, and Svelte projects.
HMR (Hot Module Replacement): when you edit and save code, it swaps only the changed part into the page instead of reloading the whole browser. It's what makes development feel fast.

One important fact here: a frontend toolchain has two jobs with opposite personalities.

The first is the job during development. The moment a developer saves, it has to respond instantly. It doesn't need to be perfectly optimized — it just has to be fast, period. Vite handed this job to esbuild (an ultra-fast transformer written in Go).

The second is the job at deployment time. The code you ship to real users has to be split into small pieces (code splitting), stripped of what it doesn't use (tree shaking), compressed, and given a debugging map (source maps). Here precision matters more than raw speed. Vite handed this job to Rollup (a JavaScript-based bundler with the most mature ecosystem of the bunch).

Here's the analogy. The old Vite was a restaurant with an ultra-fast prep counter for cooking during service (esbuild) and a separate, meticulous packing-and-logistics line for shipping (Rollup). It was a fast, sensible arrangement. But when the prep counter and the packing line play by different rules, you get headaches — the kind of bug where it worked fine in development but behaves differently once deployed. The same code runs through two different pipelines.

What changed — pinning down "old X → new Y" exactly

Vite 8 rewrote those two lines as one family called Rolldown/Oxc. Let's separate the two names first.

Rolldown: a bundler written in Rust. Its goal is "Rollup-compatible usage plus esbuild-class speed." It's the assembly line that bundles files and produces chunks.
Oxc (JavaScript Oxidation Compiler): a suite of compiler tools written in Rust — a parser that reads JS/TS, a transformer, a minifier, and so on. It's the set of cutters, gauges, and quality inspectors.

Their relationship can be captured like this.

Diagram: this section is illustrated with a flowchart — view it in the original article on var.gg.

But here's a point you have to get exactly right. It's easy to smear over with a marketing one-liner, so I checked the official migration docs myself. Here's the conclusion.

Area	Through Vite 7	Vite 8
Production build	Rollup	Rolldown
Dependency optimization (pre-bundling)	esbuild	Rolldown
JS/TS/JSX transform	esbuild	Oxc
JS minify	esbuild	Oxc Minifier
CSS minify	esbuild	Lightning CSS
Config file bundling	esbuild	Rolldown
Dev server model	native ESM	still native ESM

The last row is the key one. The dev server did not switch to "bundling all your code up front the way a production build does." Vite's default dev server still runs on the model that leans on the browser's native ES modules, and the so-called "Full Bundle Mode" that pre-bundles everything is carved out as an experimental/future feature, not the default. So it's wrong to write "Vite 8 unified development and deployment under a single bundler." The precise sentence is: "the internal substrate for bundling, transforming, and optimizing was consolidated onto Rolldown/Oxc." Why that distinction matters shows up as numbers in the benchmark shortly.

One more thing. Back in the Vite 7 era there was a separate rolldown-vite package for people who wanted to try rolldown early (an opt-in experimental build). In Vite 8 that's been folded into the main vite package itself. So a new project doesn't need to reach for rolldown-vite separately — just install Vite 8 and you're on the Rolldown path.

I ran it myself — packages vanished, the build got 13× faster

From here on, these aren't estimates — they're results I verified firsthand. I took the same React app (a 24-component dashboard using the recharts chart library and lucide-react icons), placed it on just two versions — Vite 7.3.5 and Vite 8.0.16 — and measured on the same Windows machine.

(1) Two engines collapse into one binary

Look at node_modules/.bin right after install and the difference is right there.

Vite 7  →  .bin = { esbuild, rollup, vite }     packages installed: 107
Vite 8  →  .bin = { rolldown, vite }            packages installed:  62

esbuild and rollup are gone, leaving rolldown alone. Checking the dependencies on the npm registry tells the same story — vite@8.0.16 directly depends on a single package, rolldown, while vite@7 directly depends on both rollup and esbuild. As the platform-specific binary packages of the two engines merged into one Rolldown, the number of installed packages fell from 107 to 62.

(2) The build got ~13× faster (stable across repeated runs)

Measurement	Vite 7 (Rollup)	Vite 8 (Rolldown)	Multiple
Production build, cold	2230 ms	167 ms	~13.4×
Production build, warm	2210 ms	153 ms	~14.4×
Dev server ready (cold deps)	710 ms	954 ms	0.74× (8 is slower)
Dev server ready (warm cache)	189 ms	137 ms	1.38× (8 is faster)

How you read this matters. The 13–14× on the production build is a rock-solid number that doesn't wobble across repeated runs. What took Rollup about 2.2 seconds, Rolldown finishes in the 0.15-second range.

The dev server startup time, by contrast, is not a story. Depending on cache state, 8 was slower (cold) or faster (warm). It's just jitter within the same ballpark. And that's expected — the esbuild that backed the dev server was already plenty fast. Swapping in Rolldown left no room for the dev server to get dramatically faster in the first place. What sped up is the production build, where Rollup was the bottleneck.

This meshes exactly with the point I stressed earlier — "the dev server model is unchanged." The 10× is real, but it lives behind the deploy button, not the save button.

(3) The 13× isn't the result of skipping work

Fast is meaningless if the output is flimsy. So I compared what the two builds produced.

	JS bundle output	Build success
Vite 7	602,411 B	✅ exit 0
Vite 8	588,318 B	✅ exit 0

Both produced a single bundle cleanly, and the sizes are nearly identical (Rolldown's is actually 2.3% smaller). It produced the same output 13× faster — it isn't fast because it skipped something.

Is "10–30×" real? Only if you keep the conditions attached

The official Vite 8 announcement headlines "10–30× faster builds than Rollup." It also cites real preview cases — one app's build dropping from 46 seconds to 6, that sort of figure. These numbers aren't false. But stripped of their conditions, they turn into an overstatement.

Look at the public Rolldown benchmark repo and the app under test is a massive module graph — think 10,000 JSX components plus 9,000 dependency modules. At that scale Rollup takes over 100 seconds, while Rolldown finishes in the low single-digit seconds. The "10–30×" comes precisely from that large graph, and specifically from the production build.

Our benchmark was a mere 24-component app and still showed 13× on the build. If anything, that's good evidence that the build gap is real even on small apps. That said, on an even smaller app — an empty template — other bottlenecks like tsc type checking, plugin overhead, the Windows file watcher, and antivirus loom larger, so you might not see 13×. The honest sentence is: the bigger the app, the bigger the gain, and promising a flat 30× on an empty template is an overstatement.

So does anything break? "Mostly works" isn't "works without checking"

You swapped out the entire bundler — will all your existing plugins just keep running? This is where the real cost of migration hides.

Rolldown is designed to be compatible with Rollup's plugin API. So most Vite plugins work as-is. But the official docs' phrasing is "almost fully compatible." The "almost" is the crux. One signal I checked myself: the official React plugin already got a major version bump.

@vitejs/plugin-react@5.x  →  peer: vite ^4|5|6|7  (Rollup/esbuild world)
@vitejs/plugin-react@6.x  →  peer: vite ^8         (depends on @rolldown/plugin-babel)

In other words, moving to Vite 8 means bumping the React plugin from 5 to 6 as well, and internally the babel wiring switches to a Rolldown-native plugin. It's no guarantee that "every Rollup plugin works without changing a single character."

[!WARNING]
Representative items to run through a migration checklist before upgrading Vite 7 → 8 (per the official migration guide):

build.rollupOptions → build.rolldownOptions — the name changed (the old one is deprecated).

The object form of manualChunks is unsupported — if you've built a vendor-chunk splitting strategy, it may break.

Some Rollup hooks are unsupported (shouldTransformCachedModule, resolveImportMeta, and others) — plugins that finely control advanced caching, asset URLs, or dynamic imports need checking.

The system/amd output formats are unsupported, and plugin-legacy's transpilation down to ES5 or below is unsupported — hold off if your app must support very old browsers.

CJS interop and minifier output differ — the Oxc minifier and the esbuild minifier make different assumptions, so the compressed result isn't byte-for-byte identical. Visual regression tests are recommended.

To sum up: on compatibility, "mostly works" is the right characterization. But that's different from "safe to upgrade without checking." The more plugin-dependent your app, the more that gap comes back as cost.

There's one less-obvious trade-off here. Measuring the disk myself: the package count dropped (107 → 62), but the single Rust binary was heavier. Rolldown's binary at ~23MB plus Lightning CSS at ~10MB is larger than the old esbuild's 11MB plus Rollup's 5MB (the official announcement itself notes that install size grew by ~15MB). Fewer packages doesn't mean a smaller disk footprint — you trade for speed, but the binary got bigger.

Should you migrate now? Conclusions by situation

In the face of a big tooling shift, the answer is always "it depends." Broken down concretely:

Situation	Recommendation
New Vite project	Just start with Vite 8. No reason to reach for `rolldown-vite` separately.
Small Vite 7 app	Good chance you can upgrade straight to 8 once build, tests, and preview pass in CI.
Plugin-heavy app	Safer in two steps: first isolate-test "Vite 7 + Rolldown" via `rolldown-vite`, then move up to 8.
App with complex custom Rollup output/hooks	Start by cross-checking the unsupported items in the WARNING above. Don't upgrade blindly.
Next.js users (= var.gg)	Read this less as a direct migration issue than as "where build tooling is heading." Next.js defaults to Turbopack, a bundler from the same Rust lineage.

That last row is where var.gg sits. Our frontend is Next.js, so this post isn't a record of "migrating our app." The reason I ran this verification anyway is the larger current of core JS-ecosystem tools being rewritten in native languages (Rust/Go). It's an event of exactly the same character as when I recently benchmarked the TypeScript compiler's native rewrite firsthand — instead of trusting the marketing copy, you run it yourself on a safe copy and confirm "what actually changes in our case." What a new tool absorbs and what it leaves untouched is something you can only really settle by getting hands-on with each beta or new release and running it yourself.

Wrapping up — not "fast because Rust" but "the internal contract changed"

To restate the heart of Vite 8 in one line: it's not "fast because Rust." It's that Vite rewrote the dual-engine structure it had long maintained — esbuild for development plus Rollup for deployment — around Rolldown/Oxc. The biggest promise of that shift isn't only speed; it's shrinking the difference in how modules are handled between development and deployment, inheriting as much of the Rollup plugin ecosystem as possible, and moving the internal implementation to Rust.

And running it myself gives a more honest picture than the marketing. The build was 13× faster even on a small app; the dev server, already fast, stayed roughly the same; and plugins "mostly" work, but a major version bump and a handful of unsupported items come along for the ride. For a new project there's no reason to hesitate; for an existing app, verify in stages according to its size and plugin dependence. As with every big tooling shift, the most accurate basis for judgment isn't the marketing copy — it's a single build you ran yourself.

Originally published at var.gg.

Node.js 26 Enables Temporal by Default — Time to Ditch Date?

curioustore — Fri, 10 Jul 2026 14:35:54 +0000

The morning after a deploy, the billing report arrived with an entire day blanked out. The code was one unremarkable line that pulled "from yesterday's midnight to today's midnight" — and that weekend, of all weekends, was the daylight-saving switchover. That day was 23 hours long, not 24, and the "24 hours later" I'd added with Date overshot the calendar midnight by one notch. It wasn't anyone's mistake. This is simply how JavaScript's Date behaves.

If you've ever been burned like this, you've probably heard the name Temporal at least once. It's a new time API that has been going through standardization for years as a replacement for Date. Until now you could only touch it by installing a polyfill or flipping an experimental flag — but as of Node.js 26, released on May 5, 2026, it is simply on, with no configuration at all. The global Temporal object is right there from the start, just like JSON or Math.

So I grabbed a portable Node 26 build and swapped it in myself. This isn't a release-notes roundup of "what's new in the latest version" — it's a hands-on record of why Date earned all that grief, how Temporal solves the same problems differently, and whether you can switch right now.

What happened — Node 26 just "turned Temporal on"

First, the facts. I measured on the current latest, Node v26.4.0 (2026-06-24).

node v26.4.0  | Temporal global? true
v8 14.6.202.34-node.21 | undici 8.5.0 | npm 11.17.0

That single line — typeof Temporal returning something other than undefined — is where this post begins. Temporal was a long-ripening proposal at TC39 (the JavaScript standards committee), and Node 26, by bumping its V8 engine to 14.6, promoted it to exposed by default, no flag required (per the official release notes, #61806). Browsers are following the same V8 lineage, so Temporal's status has shifted from "a standard someday" to "something now baked into the runtime."

This is also part of a broader pattern across today's runtimes. Much like Python 3.15 recently switching the default encoding for text I/O to UTF-8, more and more languages and runtimes are biting the bullet and replacing "a bad default they'd tolerated for years" in a major release. Turning Temporal on by default is a decision cut from the same cloth.

Wait, what is Temporal?

Let's start with an analogy. Date is an all-in-one Swiss Army knife that crams everything onto a single blade. "This exact moment" is a Date, "my birthday, June 29" is a Date, "the meeting is at 3 PM Seoul time" is also expressed with that same one Date. The trouble is that these three are really completely different kinds of concept. A birthday should carry no time zone, "this exact moment" is a single point that's identical everywhere on Earth, and "3 PM in Seoul" only means anything with a time zone attached. When one type has to be all three, something is always slightly off.

Temporal splits that knife into a toolbox with a dedicated tool for each job. Boiled down to the core types, it looks like this:

Temporal type	What it represents	Everyday analogy
`Instant`	An absolute point in time with no zone (one instant the whole world shares)	The exact shutter moment frozen in a photo
`PlainDate`	A date with no time and no time zone	A day circled on a calendar
`PlainDateTime`	A date and time with no time zone	A note that just says "3 PM"
`ZonedDateTime`	A complete moment with the time zone attached	A plane ticket reading "3 PM Seoul"
`Duration`	A span of time (like 2 days 3 hours)	Elapsed time on a stopwatch

You might wonder, "Why split it this finely?" The next few sections are the answer. Once it's split, the things a single Date used to get quietly wrong either can't be mixed up in the first place, or blow up as an error the moment they are.

Why Date has taken 30 years of flak

Date is an API copied wholesale from Java's already-dated Date back in the earliest days of JavaScript, in 1995. Those fingerprints are still there, still tripping people up. I ran three of them myself.

1) Months count from zero. A human writes July as 7, but Date writes it as 6.

new Date(2026, 6, 29)  => Wed Jul 29 2026   // put in 6, get July
Temporal {month: 7}    => 2026-07-29         // put in 7, get July (1-based)

2) Values change out from under you (mutability). With Date, methods like setMonth modify the original in place. Hand a Date off somewhere, and if another function changes it, your own variable changes too.

Date.setMonth(+1)   → original mutates to 2026-08-29             // share it and it's a bug
Temporal.add(+1m)   → keeps original 2026-07-29, returns new 2026-08-29  // immutable

3) String parsing is interpreted differently depending on the format. Write the same date slightly differently, and the time-zone interpretation diverges.

new Date("2026-06-29")  => 2026-06-29T00:00:00.000Z          // UTC midnight
new Date("2026/06/29")  => Mon Jun 29 2026 00:00 GMT+0900    // local midnight (different!)
Temporal.PlainDate.from("2026-06-29")  => 2026-06-29          // no concept of a time zone at all

You only swapped a - for a /, yet the result is off by nine hours. This kind of thing rarely gets caught in code review.

The real trap is time zones

You can memorize your way around those three. But the billing incident from the opening — daylight saving time (DST) — is hard to dodge by memorization. This is where the most expensive bugs in Date-based time handling come from.

DST is the practice of moving clocks forward an hour in spring (making that day 23 hours) and back an hour in fall (25 hours). Because of it, "one calendar day later" and "physically 24 hours later" can land on different days. I compared them directly at the 2026 US Eastern spring transition (March 8).

start             : 2026-03-07T12:00:00-05:00[America/New_York]
+1 day (calendar) : 2026-03-08T12:00:00-04:00   // still 12:00 midday — absorbs the DST shift
+24h  (physical)  : 2026-03-08T13:00:00-04:00   // 13:00 — pushed an hour later
Date +24h (ms)    : 13:00 once converted to Eastern   // Date only adds ms, so it's blind to DST

On Temporal.ZonedDateTime, add({ days: 1 }) understands "a day as people mean it." So even across the transition, the clock still reads 12:00. add({ hours: 24 }), on the other hand, is 24 hours of physical time, so it slides to 13:00. Both are correct. The point is that in Temporal you write down explicitly which of the two you want. Date has nothing but millisecond arithmetic, so only the latter (physical 24 hours) is ever possible — and when you meant "one calendar day," as in that billing batch, it fails silently.

This is why the types are split. With a zone-less Instant, you can't add "one calendar day" in the first place — knowing about DST requires knowing which time zone you're in (ZonedDateTime). Temporal enforces that distinction through the type system.

Diagram: this section is illustrated with a flowchart — view it in the original article on var.gg.

Calendar arithmetic: refusing instead of quietly getting it wrong

Some date calculations don't have a single clean answer. What's "one month after January 31"? There is no February 31. Date rolls it over into March without a word.

Date.setMonth(+1)  (Jan 31) => Tue Mar 03 2026   // skips February, overflows into March
Temporal.add(+1m)            => 2026-02-28        // clamped to Feb's last day (constrain)
Temporal.add(+1m, reject)    => RangeError        // rejects it: "there is no Feb 31"

By default (constrain), Temporal clamps to the last day of February; but hand it { overflow: 'reject' } and it throws an error instead of quietly patching up an invalid date. In places like accounting and settlement, where "when in doubt, stop" is the right rule, this difference is decisive. Date has no notion of "reject" at all.

So can you ditch Date? — an honest look at the limits

By this point Temporal might look like a cure-all, but this isn't a call to rip everything out today. There are honest limits, too.

The ecosystem is still catching up. Libraries like date-fns, Luxon, and Day.js, along with mountains of existing code, still pass Date objects around. At the boundaries you'll need conversions like toPlainDate() / Temporal.Instant.fromEpochMilliseconds(), and ORMs, DB drivers, and JSON serialization often don't understand Temporal types out of the box.
Date isn't going away. Temporal is an option that replaces Date, not one that removes it. Existing code keeps running as-is. "New code from here on uses Temporal" is about as realistic as it gets.
Backward compatibility. If you have to support Node below 26, or browsers that haven't enabled Temporal yet, you'll need a polyfill — and the polyfill isn't small.
The learning curve. Splitting into five types means dropping the "just use a Date for anything" habit. At first you'll hesitate every time over whether to reach for PlainDateTime or ZonedDateTime. But that hesitation is precisely what Temporal intends — Date bred bugs by letting you skip the question entirely.

In short, Temporal is not a tool that makes things shallowly easier; it's one that makes things correct the hard way. You pay an entry cost, and in return it takes away the chronic pain of time-zone and calendar bugs.

Things to check before upgrading to Node 26

Before you jump to Node 26 for Temporal alone, you should account for the compatibility changes that rode in with this major. Here's what I verified firsthand.

Removed legacy APIs. http.ServerResponse.prototype.writeHeader (use writeHead instead) and the old internal stream modules (_stream_wrap and friends) are gone for good. require('_stream_wrap') now genuinely dies with MODULE_NOT_FOUND. If an aging dependency references it, your upgrade stalls right there.
The --experimental-transform-types flag is removed, module.register() is runtime-deprecated, and the native add-on ABI version (NODE_MODULE_VERSION) rose to 147 — compiled native modules need a rebuild. On the build side there's also a bump to GCC 13.2 or newer and the end of Python 3.9 support.
Nice extras that came along for the ride. Because it's V8 14.6, you also get Map.prototype.getOrInsert / getOrInsertComputed (one-shot methods that fetch if present and insert if not) and Iterator.concat. I confirmed all three actually work.

The timeline is worth knowing too. Node 26 is promoted to LTS in October 2026, and stays Current until then. And starting with Node 27 the release model changes: one major per year (in April), with all of them LTS (InfoQ, 2026-06). In other words, 26 is the last branch of the old model, and Temporal is the biggest change riding on that final branch. For broader context on where the JS runtime ecosystem has been heading lately, I've also covered it separately in pieces on Deno 2.8's cleanup of its npm-compatible toolchain and TypeScript's move to a native compiler (tsgo).

Wrapping up — when to use Temporal

Here's my conclusion after swapping it in and using it myself.

For any new time or date logic, make Temporal the default. Especially code where "a silent one-hour or one-day drift leaks money" — time zones, DST, recurring schedules, settlement cutoffs.
Don't rewrite a huge existing Date codebase all at once — start at the boundaries (input parsing, output formatting) and move inward gradually. Converting just the inner calculations to Temporal already makes most of the bugs vanish.
For a log that just stamps "the current time" once, Date is perfectly fine. Cramming Temporal into every last corner is its own kind of overkill.

The Date that was hastily copied over 30 years ago now has a successor inside the standard runtime. Node 26 turning it on without a flag is the signal that "migrate someday" has become "evaluate now." If you'd rather not be woken at dawn by the next time-zone bug, I'd start with that one line — the one where typeof Temporal comes back true.

Originally published at var.gg.

I Ran TypeScript 7's Native Compiler (tsgo) on Our Monorepo

curioustore — Mon, 29 Jun 2026 14:43:22 +0000

I fixed one component and hit save. All I'd changed was a single line of types, yet CI's tsc --noEmit churned away for ages again. Anyone who has built a large frontend in TypeScript knows the scene. "Type checking is slow" isn't an abstract complaint — it's a wait that gets a little longer every day as your app grows.

In 2026, an answer to that wait finally arrived. Microsoft rewrote the entire TypeScript compiler in Go as a native version, codenamed Corsa, with the executable named tsgo. The headline of the official announcement was "10x faster." So I checked it for myself. I dropped tsgo straight onto the var.gg frontend monorepo that powers this very blog — a Next.js App Router project with 700-some .ts/.tsx files — and ran it side by side with the tsc we already use.

To put the conclusion up front: yes, it got faster. But "10x" wasn't what we saw in our code, and the more interesting finding wasn't the speed at all — it was that the two compilers did not report the same errors.

TL;DR

tsgo is not "a tool that compiles your TypeScript into native code." It's the TypeScript compiler itself, moved from a self-hosted JavaScript implementation to a native Go implementation. What it produces (type judgments, .js, .d.ts) is the same; the engine that produces it has changed.
Measured on our monorepo (728 files, skipLibCheck on): a full type check went from tsc 6.7s → tsgo 2.1s, about 3.2x. The official "10x" comes from large codebases like VS Code with 1.5 million lines. When a project is small or already optimized, the multiplier shrinks.
The real discovery wasn't speed but a diagnostics mismatch. tsgo (the 7.0 dev preview) caught one overload error in our code that tsc 6.0.3 let through. The first thing to look at in a migration isn't "how fast is it" but "does it give the same verdict."
As of June 2026, TypeScript 7.0 is in Beta/preview. The stable line is 6.0.x, and tsgo is a dev build shipped as @typescript/native-preview. The right strategy right now isn't to replace tsc, but to run tsgo side by side as a sidecar that measures speed and diagnostics.

One-line glossary — compiler: a program that transforms and checks human-written code so machines or other formats can work with it. TypeScript's tsc does less transforming and more "checking whether the types are correct."

The paradox of TypeScript being written in TypeScript

Until now, tsc was written in TypeScript and ran on JavaScript. Building your own compiler in your own language is called self-hosting. It wasn't a bad choice. The team got to use their own language every day (so-called dogfooding) and grow the feature set quickly.

The problem was scale. Roughly speaking, here's what the compiler does.

scanner/parser: chops the source — a blob of characters — into tokens and turns it into an AST (Abstract Syntax Tree, a tree-structured representation of source code that's easier for the compiler to work with).
binder: connects a name like foo to the declaration it refers to.
type checker: works out whether the types you wrote contradict the actual values, calls, and inheritance. Calling .toUpperCase() on a number gets caught here.
emit: from the check results, emits .js or .d.ts (a "contract" file that holds only type information, with no JavaScript implementation).
language service: a separate service responsible for the editor's autocomplete, red squiggles, rename, and go-to-definition. It uses the same information as the build.

All of this runs sequentially on a single JavaScript runtime (a single thread). As the app grows, you have to hold the AST and the type graph in memory, and the cost of GC (garbage collection) that clears away unneeded objects grows too. By analogy, it's like one skilled librarian classifying every book in a large library alone, one at a time. No matter how good the librarian is, when there are a million books the line gets long.

Why Go and not Rust — "porting," not "rewriting"

Here's a common misconception. "If they wanted performance, they should have written it in Rust — why Go?" The official FAQ's answer isn't a matter of taste. The key is the difference between port and rewrite.

The TypeScript team did not redesign the compiler. They moved it to Go while preserving the behavior and code structure of the existing compiler as much as possible. Why does that matter? Because the entire ecosystem depends on the TypeScript type system down to subtle behaviors written in no spec (so-called Hyrum's Law — with enough users, every behavior of your system, even ones not in the spec, will be depended on by somebody). The moment you redesign, the risk that those subtle behaviors drift goes way up.

So "how easy is it to port the existing code structure one-to-one" was the top criterion for the language choice. Go is structurally similar to the patterns of the existing TypeScript code, gives enough control over memory layout, and suits tree/graph processing. Rust wasn't eliminated for being slow; more precisely, redesigning around Rust's ownership and memory model would make it harder to guarantee "the same TypeScript." Because compatibility came first, they chose a port over a rewrite.

So, to stress it again — tsgo does not turn your TypeScript into Go or a native binary. What changed is the language the compiler is built in, not the output the compiler produces. Back to the library analogy: the classification rules stay the same; the change is to let several librarians split the work across sections while sharing one catalog.

TypeScript 6.0 as a bridge

To talk about tsgo, you have to start with TypeScript 6.0. 6.0 is a peculiar release. The official announcement describes it as "the last major release for the existing JavaScript codebase" and a "bridge to crossing over to 7.0's Go native." In fact, there are no plans to make TypeScript 6.1, and the 6.0 line will only receive patches focused on security, severe regressions, and 6/7 compatibility issues.

What 6.0 does is "clean up the present for the future." It changes defaults (e.g. strict, types: []) and marks old options as deprecated. And it gives you a safety pin to silence those warnings temporarily: "ignoreDeprecations": "6.0".

But don't mistake this safety pin for a migration strategy. In TypeScript 7, those deprecated options aren't supported at all. That means the list of warnings you hid in 6.0 is exactly the list of hard-error candidates in 7.0.

Here we had a small bit of luck. The var.gg frontend is already on typescript ^6.0.3 — that is, we're standing on the bridge. That's a much further-along starting line than projects still on 5.x. Here are some representative items worth checking ahead of time on 6.x.

Item	Change in 6.0	7.0 perspective	Checkpoint
`strict`	default `true`	strict worldview in 7 too	little impact if already strict
`types`	default `[]`	implicit `@types/*` inclusion reduced	declare global types like `node`, `jest`, `playwright` explicitly
`baseUrl`	deprecated	slated for removal in 7	check whether `paths` aliases lean on `baseUrl`
`moduleResolution: node10`	deprecated	`nodenext`/`bundler` recommended	for bundler apps, is `bundler` the natural fit?
`target: es5`	up for cleanup	removed	is backward compat handled at the bundler layer rather than in TS?

Interestingly, when I dug through our code I found that some scripts already had ignoreDeprecations: "6.0" baked into their compile options. A small sign that standing on the bridge doesn't mean "ready to go."

I ran it on our own monorepo

Now the heart of it. Instead of re-citing the official benchmark table, I measured directly in our code.

Target: apps/frontend (Next.js App Router, 728 .ts/.tsx files under src)
tsconfig: noEmit: true, incremental: true, skipLibCheck: true, strict: true
Comparison: tsc 6.0.3 vs tsgo (@typescript/native-preview, version 7.0.0-dev.20260616.1)
Command: --noEmit on both sides (pure type-check time)
Environment: Windows 11, Node v24.15.0
cold = first run after removing the incremental cache (tsconfig.tsbuildinfo), warm = a re-run with the cache present

Installation is a one-liner. Anyone can reproduce the exact same thing in their own project.

npm i -D @typescript/native-preview@beta
# the executable is named tsgo
npx tsgo -p apps/frontend/tsconfig.json --noEmit

Speed

Compiler	Version	cold	warm
`tsc`	6.0.3 (JS self-hosted)	6.7s	1.9s
`tsgo`	7.0.0-dev (Go native)	2.1s	0.7s
speedup		≈ 3.2×	≈ 2.7×

It got faster. When a cold 6.7s drops to 2.1s, that's a difference you feel on every PR in a CI environment with no cache. But it wasn't 10x. And that's normal — I'll explain why below.

And the two compilers did not report the same errors

What really made me sit up wasn't the speed.

Compiler	Error count	Details
`tsc` 6.0.3	3	all stale references in Next.js-generated `.next/types/**` (`TS2307`) — not source bugs
`tsgo` 7.0-dev	4	same 3 above + 1 additional ↓

The one line only tsgo flagged:

src/features/abbreviations/hooks/useInfiniteAbbreviations.ts(82,9):
  error TS2769: No overload matches this call.

In useInfiniteQuery({ … initialData: transformedInitialData … }), overload resolution (the several call forms of one function) went different ways. tsgo rejected it; tsc 6.0.3 let it through. Same code, different verdict.

Here I have to be honest. tsgo is the 7.0 dev preview and tsc is the 6.0.3 stable release — the type checker versions themselves differ. So whether this difference is (a) a check 7.0 intentionally strengthened, (b) a preview bug, or (c) a 6.0→7.0 difference in overload selection, I can't say for sure right now. But the conclusion is clear: the preview's diagnostics don't yet match tsc 100%. And this isn't a drawback — it's the very first thing someone preparing for a migration needs to know.

Where does 10x come from, and why was it 3x for us

The official "10x" isn't hype. Its source is clear. In the 2025 A 10x Faster TypeScript announcement, Microsoft published a table measuring real open-source projects.

Project	LOC	existing `tsc`	native	ratio
VS Code	1,505,000	77.8s	7.5s	10.4×
Playwright	356,000	11.1s	1.1s	10.1×
TypeORM	270,000	17.5s	1.3s	13.5×
date-fns	104,000	6.5s	0.7s	9.5×

You can see what they have in common. They're all hundreds of thousands to a million lines — code where type checking is genuinely heavy. By that standard our apps/frontend is on the small side, and on top of that it skips library type checking via skipLibCheck, so tsc's original cost was already low. The conditions for a smaller multiplier are roughly these:

when the project is small, or more bound by file reading (I/O)
when it's already optimized with skipLibCheck and explicit types
when the CI machine has few cores, so tsgo's parallelism is less exercised
the fact that tsgo --noEmit is only a type check and doesn't replace the entire next build

So there are two sentences this post has to keep separate: "There is an official 10x" (a fact with evidence) and "we got 10x in our code" (a claim you're not allowed to make until you measure it yourself). Our honest answer is ~3x. It may look small, but in a cacheless CI, 6.7s becoming 2.1s is a clear gain the more it repeats.

The speed comes from two things. One is the efficiency of Go native itself; the other is parallelization. The 7.0 Beta runs parsing, type checking, and emit in parallel, tuning the number of type-checking workers with --checkers and parallel project builds with --builders (there's also --singleThreaded for debugging). It's like opening several checkout lanes. But type checking isn't "ring up this customer's items and you're done" — it's entangled with other files, libraries, and generic inference, so parallelization isn't simply splitting files N ways; it's the problem of dividing the work while controlling shared knowledge and ordering dependencies.

What tsgo doesn't give you yet

Don't take the word preview lightly. Looking at the current support table for microsoft/typescript-go, parsing, type checking, build mode, and incremental builds are mostly marked "Done," but there are still blanks.

watch mode: still a prototype. It can watch for file changes, but incremental re-checking isn't optimized.
Compiler API: not ready. A stable API for calling the compiler's internals from code is signaled for 7.1 or later at the earliest. This is the core risk for the ecosystem.
JS/JSDoc, .d.ts emit from .js: there are areas where behavior intentionally differs.

The Compiler API in particular is a quiet landmine. The following tools read TypeScript's internal API directly, so they don't automatically come along just because you switch tsc.

Category	Why it's risky
`typescript-eslint` (type-aware lint)	reads the TypeScript API for type information
`ts-node`, `ts-jest`	import the `typescript` package at runtime
custom transformers (`ts-patch`, etc.)	depend on the existing AST/transform API
framework plugins like Vue/Angular	use the language service plugin / compiler API

Microsoft acknowledges this too, providing separate compatibility packages (@typescript/typescript6, tsc6) for existing API consumers. In other words, they've officially admitted that "the compiler CLI gets faster, but the ecosystem that leans on the API needs a separate path."

And not every fast tool does the same job. Let me lay out the boundaries with esbuild, SWC, and Biome — the ones people commonly confuse here.

Tool	Type checking	Speed	Suited for
`tsc` 6.x	full TypeScript type checking	baseline	current production baseline
`tsgo` / TS7	aims for full type checking	~10x on large code	fast type checking, validating the future transition
esbuild	none (treats types like comments)	very fast	bundling/transpiling
SWC	none (per-file transform)	very fast	fast transforms in build pipelines like Next
Biome	none (formatter/linter)	very fast	partial replacement for Prettier/ESLint

The key distinction is this. esbuild, SWC, and Biome can speed up the TypeScript "development experience," but they are not type checkers that judge the whole type system the way tsc and tsgo do. The moment you believe a fast transpiler stands in for type checking, bugs leak out. To actually trust your types, you ultimately need tsc or tsgo. This question of "how far you can tame nondeterminism with tooling" is one I touched once on the Python side in a post on type-safe agents — different language, same grain of worry.

So what to do now

Putting it together, the right answer in June 2026 isn't "ditch tsc and switch to tsgo" but "run the two side by side." Here's the decision flow as a diagram.

📊 The diagram for this section renders in the original article on var.gg →

In words, here it is.

First clean up the warnings you hid with ignoreDeprecations and the deprecated options. The list you hid is the list of errors in 7.0.
Add @typescript/native-preview@beta as a devDependency.
Measure tsc --noEmit and tsgo --noEmit repeatedly, 7+ times. Look at the diagnostics diff before the average time.
If the diff is 0, add tsgo as a non-blocking CI job to keep collecting speed and diagnostics. It's safe because a failure won't block the build.
Until the 7.0 stable release and API stabilization, keep typescript-eslint, the test runner, and custom transformers on the existing TS6 API path.

We finished steps 1–3 with this round of measurement, and because the diagnostics diff wasn't 0 (the TS2769 above), we didn't jump straight to step 4 — we're looking into the cause of that one line first. This doesn't mean "the slower tool is smarter" — it's just the obvious procedure of confirming you get the same answer before switching to a faster tool. The habit of adding one more layer of verification in an era when tools are changing also chimes with what I said in a post on what git tools should become in the agent era.

Conclusion — not a swap, but being ready to measure for yourself

The TypeScript 7 native compiler is an uncommon kind of event. It's a transplant at the heart of the ecosystem — a language moving a compiler that had been written in itself over to another language, straining not to break compatibility. The speed improvement is no exaggeration even going by the official numbers alone, and there's a good chance there's a real gain for a TS monorepo like ours too.

But wholesale-replacing the typescript package right now and pushing even the API-leaning tools across all at once is premature. The most balanced stance is this — on top of TS 6.0.3, clean up the deprecated options, run tsgo --noEmit side by side, and measure diagnostic equivalence and speed for yourself. What that one round of measurement on our monorepo told us was two things: the honest number "about 3x at our scale," and the more valuable warning that "the preview doesn't give the same errors yet."

Being fast isn't the finish line but the starting line. First confirm you get the same answer, then enjoy the speed you've gained. And that confirmation is something anyone can start on their own code today, with the single line npx tsgo --noEmit.

References: TypeScript 7.0 Beta official announcement · A 10x Faster TypeScript · microsoft/typescript-go repository · benchmarks measured directly on var.gg apps/frontend on 2026-06-16.

Python 3.15's UTF-8 Default (PEP 686): I Verified the Silent Byte Changes on Windows

curioustore — Mon, 29 Jun 2026 14:43:19 +0000

I ran the same Python script on two versions. Both print 문서 to the screen, identically. But the moment I redirected that output to a file with > out.bin, the bytes left on disk diverged. One side wrote 4 bytes, the other 6.

python 3.14.6:  b9 ae bc ad
python 3.15.0b2: eb ac b8 ec 84 9c

Not a single line of code changed. I only bumped the interpreter version, yet the same characters 문서 get written to disk as different bytes. This is the defining scene of the change coming in Python 3.15, which ships its final release on October 1, 2026. The contract isn't the characters you see on screen — it's the bytes that actually get stored.

This article is a hands-on record of touching that change directly. On a Korean-language Windows environment, I pulled down two real builds, Python 3.14.6 and 3.15.0b2, and ran the same code A/B to verify — byte by byte — what changes and what doesn't, and where the silent breakage that's more dangerous than an outright error shows up.

[!NOTE]
Every measurement in this article was obtained by the author personally running two of python.org's embedded (portable) builds — python-3.14.6-embed-amd64 and python-3.15.0b2-embed-amd64 — under a Windows 11 Korean locale. 3.15.0b2 is the second beta, released on June 2, 2026; the feature is fully implemented, but this is not yet a production-recommended version.

Before we begin: encoding as a "translation dictionary"

Before the main discussion, let me plainly define a few terms you'll need to follow this article all the way through. Readers who already know them can skip ahead.

Computers don't understand characters. What gets stored on disk is, ultimately, a sequence of numbers (bytes). So we need an agreed-upon rule for which character gets written as which bytes, and that rule is called an encoding. Think of it as a translation dictionary that converts back and forth between characters and bytes.

UTF-8 — the de facto standard encoding of today's internet and modern text files, representing every character in the world in 1–4 bytes. A single Hangul character is usually 3 bytes.
CP949 — the Korean code page (the Windows-style character table) Microsoft uses. A single Hangul character is 2 bytes. Old Windows Korean-language programs, .txt files saved from Notepad, Excel CSVs, and the like commonly use this encoding. (It has the aliases ms949 and uhc, and while it overlaps heavily with its cousin euc-kr, the two are not the same standard.)
Locale — the operating system's bundle of regional settings (language, country, date format, and so on). Traditionally, the locale also decided the default for "what to use when no encoding is specified." The default code page on Korean Windows is usually 949, i.e. CP949.
UTF-8 mode — a runtime switch decided when Python starts. When it's on, Python uses UTF-8 instead of the locale for several defaults. PEP 686 is exactly what flips this switch's default.

If I had to state the crux in one sentence, it's this.

Python 3.15 does not convert your existing CP949 files to UTF-8. It only swaps the default translation dictionary that Python picks on your behalf when you don't specify an encoding — from "regional convention (CP949)" to "UTF-8."

When a package has no label describing its contents, the recipient has to guess what's inside by convention. Code that omits encoding= is like a box with that label torn off. PEP 686 is a policy that changes the default convention to "if an unlabeled box arrives, assume UTF-8." The data inside the box itself doesn't change.

Exactly what changes — the defaults I measured directly

First I launched both interpreters with no options and printed out the defaults. This is an environment where the Korean ACP (ANSI code page) is 949.

Item	Python 3.14.6	Python 3.15.0b2
`sys.flags.utf8_mode`	`0`	`1`	← the master switch flips
`open(path)` default encoding	`cp949`	`utf-8`	← the core change
`sys.stdout.encoding` (file/pipe)	`cp949`	`utf-8`	← changed
`locale.getpreferredencoding(False)`	`cp949`	`utf-8`	← changed
`locale.getencoding()`	`cp949`	`cp949`	unchanged
`sys.getfilesystemencoding()`	`utf-8`	`utf-8`	already UTF-8
`encoding="locale"` explicit	`cp949`	`cp949`	unchanged
`encoding="utf-8"` / `"cp949"` explicit	as-is	as-is	unchanged

Let me start with the point that's most often misunderstood. The filesystem encoding (how file names and paths are handed to the OS) is already UTF-8 in both versions. On Windows it has been ever since PEP 529 in Python 3.6. In other words, the ability to find a file name like C:\자료\한글.txt does not change this time. What changes is the default dictionary used when moving the contents of that file between bytes and strings.

These are two completely separate questions.

Can you locate a file named C:\자료\한글.txt? → path encoding (unchanged)
Do you read that file's contents as CP949 or as UTF-8? → text I/O encoding (changed this time)

Same program, different bytes

open(p, "w").write("한글 데이터: 매출 1234원") — I ran this write, with no encoding specified, on both versions and compared the bytes left on disk.

3.14.6 (cp949):  24 bytes  c7 d1 b1 db 20 ... bf f8
3.15.0b2 (utf-8): 32 bytes  ed 95 9c ea b8 80 20 ... ec 9b 90

The write succeeds without error on both sides. I only bumped the interpreter, yet the output file's bytes silently change. The breakage surfaces not here, but later, in whoever else reads that file — an Excel that expects CP949, an older Notepad, the neighboring team's legacy script.

Distinguishing the three layers

Why does the "screen is fine but only the file changed" situation arise? Because Windows text I/O is actually split across three different boundaries.

📊 The diagram for this section renders in the original article on var.gg →

A directly attached modern Windows console (Windows Terminal and the like) has used the Unicode API since PEP 528, so Hangul already prints fine even on 3.14. So if you see print("한글") come out cleanly on screen and conclude "the default encoding must be the same," you'd be wrong. When you speak to the screen, a translator was already standing by; what changed this time is the envelope spec used when you mail a letter to a file or a pipe. The 문서 redirect experiment at the very top of this article — where the screen (or pipe) and the disk bytes diverged — happened for exactly this reason.

Why now — nine years in the making

PEP 686 isn't a brand-new feature that popped up out of nowhere. It's a carefully pre-announced compatibility change that flips only the default of a UTF-8 mode that has been available for years already.

Point in time	Change	Role
Python 3.6	PEP 528·529	Modernized the Windows console and filesystem paths around UTF-8 (already complete)
Python 3.7	PEP 540	Introduced the switch called UTF-8 mode — but default OFF, activated manually with `-X utf8`
Python 3.10	PEP 597	Introduced `EncodingWarning` and `encoding="locale"` — tools to find where implicit encoding is used
Python 3.11	preparatory work	Corrected behavior so that even in UTF-8 mode, `encoding="locale"` uses the real locale
Python 3.15	PEP 686	Flips the default of that switch to ON

The interesting part is the timeline itself. PEP 686 was first discussed targeting Python 3.13, but the Steering Council asked for 3.15 to allow a longer preparation period, and it was approved on that condition in June 2022. It was deliberately brought in slowly, as a change whose compatibility ripple effects were well understood.

Whether it actually landed in 3.15.0b2 cross-checks three ways. (1) PEP 686's status is Final and its target is 3.15. (2) The 3.15.0b2 release notes call it out as a major change. (3) The "What's New in Python 3.15" document states that I/O which omits the encoding — like open() — uses UTF-8. And above all, the measurements in the table above are direct evidence.

"Silent breakage" — more dangerous than an error

This is where the real trap of this change begins. It's easy to think, "So if I read a CP949 file with 3.15, it'll throw an error, right?" That's only half right. And the case where it does error is actually the lucky one.

Common Hangul fails loudly (the lucky case)

Reading 한글 saved as CP949 with 3.15's default open() (UTF-8):

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 0

Conversely, reading 한글 saved as UTF-8 with 3.14's default open() (CP949) also throws UnicodeDecodeError. The Hangul byte patterns of CP949 and UTF-8 are, for the most part, mutually "grammatically impossible combinations," so reading them the wrong way blows up immediately with an exception. It's loud. Loud is good. It lands in the logs, gets caught by try/except, and is discovered before deployment.

But some bytes silently become different characters

The problem is the range that is CP949 bytes and simultaneously valid UTF-8. Such bytes throw no error read either way. They just become a different character.

I counted by brute force, and among 2-byte sequences there were 1027 cases that decode "without error in either codec, yet differently from each other." I reproduced two representative examples by actually reading them from files.

Disk bytes	3.14.6 default (CP949) read	3.15.0b2 default (UTF-8) read	Error?
`c2 af`	`'짱'`	`'¯'` (macron symbol)	No error in either
`eb ac b8 ec 84 9c`	`'臾몄꽌'`	`'문서'`	No error in either

Same file, same single line of open(p).read(). Only the interpreter differs, yet the resulting string is completely different — and there's no exception anywhere. No log, no traceback. The wrong data simply loads into memory as-is and gets re-saved or re-transmitted as-is. This is why it's more dangerous than UnicodeDecodeError: an error can be caught, but silent mojibake — a state where the bytes were successfully interpreted but the characters are garbled — gives you not even a clue to catch.

[!WARNING]
The default error handling for open() is strict in both versions. But what strict checks is only "is this byte valid under this encoding's grammar," not "are these the right characters that were originally intended." The c2 af → ¯ above is perfectly valid UTF-8 grammatically, so strict lets it pass too.

Where it's costlier and surfaces later: writes and appends

The silent breakage on reads is scary, but the costlier accident in a migration actually happens with writes and appends — because the damage surfaces much later.

Suppose 3.15 appends one line, with its default (UTF-8), to a log file that had already been accumulating as CP949. Here's what I reproduced directly.

# 기존 CP949 로그에 3.15 기본 open(..., "a")로 append
open("mixed.log", "wb").write("기존=한글\n".encode("cp949"))
with open("mixed.log", "a") as f:   # 3.15 기본 = UTF-8
    f.write("추가=문서\n")

Append doesn't inspect the existing file contents. It just tacks UTF-8 bytes onto the end. The result is a mixed-encoding file that's CP949 in the front and UTF-8 in the back.

raw: b1 e2 c1 b8 3d c7 d1 b1 db 0a | ec b6 94 ea b0 80 3d eb ac b8 ec 84 9c 0d 0a
     └──────── CP949 ───────────┘   └──────────── UTF-8 ─────────────────┘

If you then try to read this file in its entirety:

cp949 full decode → UnicodeDecodeError
utf-8 full decode → UnicodeDecodeError

It has become a file that can't be read by any single encoding. Yet at the moment of appending there was no error at all. The accident surfaces only weeks later, in log analysis, a backup restore, or a downstream ETL. By then both the original and the exact transition point are hazy.

There's one more, similar trap. CP949 can't represent every Unicode character (emoji, certain symbols, and so on). So on 3.14, f.write("상태🙂") could fail early with a UnicodeEncodeError. 3.15, being UTF-8, writes this quietly and successfully. On the surface it's an improvement, but if the consumer is still CP949, the old early warning has vanished and the compatibility problem has simply been pushed downstream.

To summarize the risk types:

Type	Example	Does `strict` block it?	Risk
Wrong read, byte grammar also mismatches	CP949 `한글` as UTF-8	Blocks (exception)	Found immediately — lucky
Wrong read, valid under both grammars	CP949 `짱` as UTF-8	Doesn't block	Silent mojibake
New file written in a different encoding	3.15 generates a UTF-8 log	Doesn't block	Found at the consumption stage
UTF-8 append to a CP949 file	Mixed-encoding file	Doesn't block	Delayed failure, harder to recover
Re-saving a wrongly-read string	Permanently storing mojibake	Doesn't block	Hard to recover without the original

subprocess: when you capture the tool next door

Silent change isn't confined to files. It's also in subprocess(text=True), which calls an external program and receives its output — because a fair number of Korean Windows console tools still emit CP949 bytes.

I created a child process that outputs CP949 and had the parent capture its output with text=True.

3.14.6 parent: normal capture (rc 0).
3.15.0b2 parent: because the parent's pipe decoder is UTF-8, the moment it meets a CP949 byte the reader thread crashes with UnicodeDecodeError.

The subprocess API itself wasn't redesigned in 3.15. The default codec of the TextIOWrapper the parent wraps around the pipe follows sys.flags.utf8_mode, and this is a chain reaction caused by that default flipping 0 → 1. Looking at the CPython source, the logic is identical across both versions.

# Lib/subprocess.py (3.14.6 == 3.15.0b2)
if sys.flags.utf8_mode:
    return "utf-8"
return locale.getencoding()

[!WARNING]
A subtle trap: if you bump both the parent and the child to 3.15, both switch to UTF-8 together and the test passes. But that success does not prove compatibility with actual CP949 legacy tools. So when verifying, you must make the child emit fixed encoding bytes.

The safety net is "explicit," not "automatic"

So how do you prepare? The core conclusion first: encoding= is not an optional argument but a protocol declaration. In every place where bytes cross a process boundary — files, pipes, external tools — declaring the actual data contract is the only version- and OS-independent safety net.

The precise meaning of `encoding="locale"`

Here's a common misunderstanding. "To keep the old behavior, can't I just use encoding="locale"?" Only partly right. encoding="locale" (PEP 597, 3.10+) means "use this machine's locale encoding right now," not "use CP949." I confirmed directly that on 3.15 this expression still behaves as intended and read CP949 files correctly on a Korean machine. But run the same code on Japanese or English Windows, or on a UTF-8 ACP environment, and it changes again.

The right expression differs per data contract.

Data contract	Recommended expression
This format is UTF-8 everywhere	`encoding="utf-8"`
This legacy format is CP949 everywhere	`encoding="cp949"`
The file is designed to follow the current user locale	`encoding="locale"`
External data of unknown encoding	Don't auto-guess — check the metadata/protocol, or receive it as binary and validate

If you're dealing with a fixed CP949 format, encoding="cp949" is a stronger contract than "locale".

Toggles and precedence

The default changed, but the option didn't disappear. Here's the precedence I confirmed directly.

-X utf8 / -X utf8=0   (command line, highest priority)
   >  PYTHONUTF8=1 / =0   (environment variable)
   >  version default  (3.14 Windows = 0, 3.15 = 1)

On 3.15, PYTHONUTF8=0 or -X utf8=0 → immediately rolls back to the old CP949 behavior (reconfirmed utf8_mode 0, getpreferredencoding cp949).
On 3.14, PYTHONUTF8=1 or -X utf8 → rehearse the 3.15 behavior in advance. Without a separate 3.15 install, you can pre-check whether your current codebase breaks under UTF-8 mode.
PYTHONIOENCODING applies with priority only to the standard streams; it cannot change the defaults of ordinary open() or subprocess pipes. Don't overestimate its scope.

Migration priorities

This is the order I'd recommend, based on the behavior I verified directly.

For each file and pipe, confirm what encoding the actual producer and consumer use. (First, and most often skipped.)
Pin the formats we newly create with encoding="utf-8".
Pin actual CP949 contracts with encoding="cp949", then draw up a separate migration plan.
Use encoding="locale" only when following the user locale is a genuine requirement.
Audit where implicit encoding is used with -X warn_default_encoding (or -W error::EncodingWarning).
A system-wide PYTHONUTF8=0 is not a root fix — keep it only as a last resort for dodging an outage.

Configuration files, logs, caches, CSV exports, and external CLI calls in particular are more easily missed in audits than the main code. And if a third-party library internally calls open(config) or subprocess(text=True) without an encoding, you're affected even if your own code is clean. Here too, the top priority is finding the actual execution path with EncodingWarning.

Closing — the direction is right, but the lesson is the opposite

The direction of PEP 686 itself is sound. UTF-8 is already the de facto standard of the internet and modern text, and it narrows the long-standing asymmetry where an open("README.md") that ran fine on Linux broke only on Windows. For a cross-platform project starting fresh, it's clearly less painful.

But the compatibility cost is much wider than "reading a CP949 file throws an error." Compressing the conclusions I reached firsthand:

Some CP949 bytes are also valid UTF-8 and silently become different characters (짱 → ¯).
The bytes of new logs and export files change to UTF-8 without error.
Appending to an existing CP949 file produces a mixed file that's readable by no single codec.
If both parent and child move up to 3.15 together, subprocess tests yield a false positive.
Because the console and filesystem are already UTF-8, a simple on-screen test misses the change.

So the practical lesson of this change is not "you can now omit encoding=." Quite the opposite.

Python 3.15 made the implicit default more reasonable. But for long-term archival files, logs, pipes, and external-program protocols, explicit encoding is the only real safety net.

Characters showing up fine on screen and the correct bytes being written to disk are different problems. 3.15 reminds us — quietly, but unmistakably — that the two are not the same.

This article follows the same methodology — firsthand verification that pulls down two versions directly and contrasts their behavioral differences in bytes and measurements — and is a sibling to the direct TypeScript native compiler (tsgo) benchmark and the PostgreSQL 19 deep-dive verification.

References (official docs)

Did Deno 2.8 Swallow the npm Toolchain? I Ran install, ci, audit, and pack Myself

curioustore — Mon, 29 Jun 2026 14:41:16 +0000

Same project, same dependencies. And yet, when I asked both tools "how many vulnerabilities do you have?", they answered differently.

$ npm audit
2 vulnerabilities (1 high, 1 critical)

$ deno audit
Found 7 vulnerabilities
Severity: 0 low, 3 moderate, 3 high, 1 critical

I didn't change a single character of package.json. I deliberately pinned just two packages — lodash@4.17.15 and minimist@1.2.5 — to old versions, then ran npm install and deno install separately. And yet npm says "2" while Deno says "7." Neither was lying — as we'll see later, the two were looking at the same database but counting in different ways.

This small discrepancy points precisely at the subject of this article. Deno has long claimed to "replace Node." Usually we hear that as the problem of swapping node server.js for deno run server.ts. But what we actually reach for several times a day in real work isn't the runtime — it's the package-manager routines: you pull dependencies (install), reproduce them identically in CI (ci), scan for vulnerabilities (audit), and build a distributable bundle (pack). Deno 2.8 walked right into this territory.

So I narrowed the question to this: leaving the runtime as Node, can you simply swap in the Deno CLI for npm install, npm ci, npm audit, and npm pack on the same package.json project? To see whether it actually works rather than taking the marketing copy at face value, I set up Windows 11 + Node v24.15 + Deno 2.8.0 and ran all five head-to-head with the same fixture.

[!NOTE]
This article is an experiment pinned to Deno 2.8.x. By the time I was writing it up on 2026-06-25, Deno 2.9.0 had already shipped, and 2.9 added a feature that automatically seeds deno.lock from package-lock.json, pnpm-lock.yaml, and the like. In other words, the initial lockfile migration behavior changes in 2.9. The numbers and behaviors below are all relative to 2.8.0.

First, just five terms — let's start with "what these are"

Before going deep, let me lay down only the minimal vocabulary you need to read this article, in plain terms. Readers who already know this can skip ahead without losing the thread.

Runtime: the engine plus the bundle of standard APIs that actually executes JS/TS code. Node, Deno, and Bun fall here. Think of it as different orchestras playing the same score (your code).
Package manager: the tool that downloads external libraries, pins their versions, and assembles node_modules. npm, pnpm, Yarn, Bun — and now the Deno CLI — compete for this spot.
lockfile: a file recording the exact version, download URL, and integrity hash of every package actually installed. For npm it's package-lock.json; for Deno it's deno.lock. It's a receipt that says not "3 tomatoes" but "3 tomatoes shipped from Farm A on June 25".
frozen (reproducible) install: an install mode that does not refresh the lockfile and simply fails if the lockfile and package.json disagree. It's cooking strictly to a sealed recipe and stopping if the ingredient list changes. It's the key device for preventing "but it worked on my laptop" in CI.
audit DB: a database collecting the names and version ranges of vulnerable packages. The audit command checks your lockfile against this list. It's cross-referencing the food in your fridge against a recall list.

Now that the terms are in hand, let's walk through the five scenes I actually ran, one at a time.

Scene 1 — `install`: same downloads, but faster, and stacked differently

The first thing I measured was install time from a cold state. npm ran as usual; for Deno I emptied DENO_DIR (the global cache location) to a new directory to make it genuinely cold before running.

Item	`npm install`	`deno install`
cold install time (3 deps)	1,744 ms	559 ms (~3.1x faster)
lockfile produced	`package-lock.json`	`deno.lock` (no package-lock generated)

Deno was 3x faster. But if you just parrot the commonly cited "Deno is 3.66x faster than npm" line, you'll get it wrong.

[!WARNING]
The Deno official blog's "3.66x faster" is not a figure relative to the npm CLI. It's the improvement from Deno 2.7 (3,319ms) → Deno 2.8 (906ms) when running a benchmark that downloads React, Vite, Babel, and ESLint on Linux with a fresh DENO_DIR. In other words, it's "new Deno vs. old Deno." The ~3.1x I measured is a separate thing — Deno 2.8 vs. the npm CLI on Windows with the same fixture — and on top of that, npm's global cache (~/.npm) was already warm, yet cold Deno still won. A fully cold npm would have been slower. The honest reading is to take it as a "direction" rather than the multiple itself.

More interesting than the speed was how things get stacked. When I looked at the top level of the node_modules each tool produced, the structure differed.

# npm: flat hoist — direct 3 + transitive 5 = all 8 at top level
node_modules/
  ansi-styles/  chalk/  color-convert/  color-name/
  has-flag/  lodash/  minimist/  supports-color/

# deno: junction isolation (pnpm style) — only the 3 "declared" at top level
node_modules/
  .deno/            <- the real thing lives here, isolated under .deno/<pkg>@<ver>/
  chalk    -> junction
  lodash   -> junction
  minimist -> junction

npm pulls even transitive dependencies (packages I didn't write down directly but that chalk dragged in, like has-flag) all the way up to the top level and lays them out flat. Deno exposes at the top level only the 3 I wrote directly into package.json, as junctions (Windows directory shortcuts), and hides the rest inside .deno/. You could liken it to npm spreading out the entire warehouse for every project, while Deno keeps a shared distribution warehouse and only sets up the display shelves.

This structural difference isn't an abstract matter of taste. It immediately splits how code behaves.

Scene 2 — phantom dependency: the same code worked on one side and failed on the other

I deliberately tried to require has-flag (a transitive dependency dragged in by chalk) even though it isn't written anywhere in package.json.

// phantom.js
const x = require("has-flag");
console.log("phantom require ok:", typeof x);

# node (flat node_modules)
$ node phantom.js
phantom require ok: function      <- success

# deno (junction isolation)
$ deno run -A phantom.js
error: Cannot find module 'has-flag'   <- failure

Same file, a node_modules folder of the same name — yet the results are exact opposites. Because npm's flattening lifts even undeclared packages to the top level, the require happens to succeed — and this is the notorious phantom dependency. Your code is secretly leaning on a library you never wrote into package.json, and then one day chalk swaps out its dependencies and you get an inexplicable build failure. Deno's isolation structure makes only what you declared visible, blocking this accidental dependency from the start.

This isn't a simple "Deno is stricter" ranking — it's a signal that the behavior is different. Some tools written assuming a flat layout can break under Deno's isolation structure (which is why Deno 2.8 also added a hoisted linker option that lays things out flat like npm). This "only what you declared is visible" philosophy runs along the same grain as the way uv bolted a security-inspector role onto the package install tool — and the next scene is exactly that audit story.

Scene 3 — `ci`: both "stop if you break the seal," but their tone differs

npm ci is a command for CI. If the lockfile is missing or disagrees with package.json, it refuses to install; it deletes the existing node_modules and then reproduces strictly from the lockfile. Deno 2.8's deno ci has nearly the same intent — the official docs describe it as roughly equivalent to rm -rf node_modules && deno install --frozen.

To check, I changed only the lodash version in package.json so it disagreed with the lockfile (deliberately not updating the lockfile) and ran both sides. Both failed correctly. The failure is the feature — stopping when you try to buy an ingredient that isn't on the sealed receipt is the heart of reproducibility. The difference was the tone of the refusal.

# npm ci
npm error code EUSAGE
npm error `npm ci` can only install packages when your package.json and
npm error package-lock.json ... are in sync. Please update your lock file
npm error with `npm install` before continuing.
npm error Invalid: lock file's lodash@4.17.15 does not satisfy lodash@4.17.21

# deno ci
error: The lockfile is out of date. Run `deno install --frozen=false`,
       or rerun with `--frozen=false` to update it.
changes:
 5 | -    "npm:lodash@4.17.15": "4.17.15",
 5 | +    "npm:lodash@4.17.21": "4.17.21",
34 | -    "lodash@4.17.15": { ... }
35 | -      "integrity": "sha512-8xOcRHvCjno..."
35 | +      "integrity": "sha512-v2kDEe57lec..."

npm wraps it up briefly: "they don't match, so refresh the lock with npm install." Deno goes a step further and shows a precise diff that even includes the integrity hashes — it spreads out, right there, which line of the lockfile should change and how. When you're tracking down "why did this break" in a CI log, that difference matters more than you'd expect. Standing two versions side by side and seeing which one gives the friendlier diagnostic is the same verification attitude I took when I compared tsgo (the native TypeScript compiler) head-to-head against the old compiler.

Scene 4 — `audit`: the truth behind 2 vs. 7

Now back to the puzzle from the opening. npm says "2," Deno says "7." Reading the output all the way through made the answer clear — the two were looking at the same database. Both cited the same GHSA- identifiers from the GitHub Advisory.

# npm audit — counts by "package"
lodash  <=4.17.23   Severity: high   (6 advisories folded into 1 line)
minimist  1.0.0 - 1.2.5   Severity: critical
=> 2 vulnerabilities (1 high, 1 critical)

# deno audit — counts by "advisory," one by one
Command Injection in lodash ............ GHSA-35jh-r3h4-6jhm  high
Prototype Pollution in lodash .......... GHSA-p6mc-m468-83gw  high
ReDoS in lodash ........................ GHSA-29mw-wpgm-hmr9  moderate
... (6 lodash advisories expanded)
Prototype Pollution in minimist ........ GHSA-xvch-5gv4-984h  critical
=> Found 7 vulnerabilities (3 moderate, 3 high, 1 critical)

npm counts "how many packages are vulnerable" (lodash 1 + minimist 1 = 2), while Deno counts "how many advisories were hit" (lodash 6 + minimist 1 = 7). They merely aggregate the same threat in different units — neither is wrong. So when you compare the two tools' audit results, you should line up not the "counts" but the advisory IDs, vulnerable version ranges, and dependency paths.

[!WARNING]
It's safest not to assert exactly which DB deno audit uses. Even Deno's own docs phrase it differently — the 2.6 announcement post says "GitHub CVE database," the deno audit CLI docs generally say "vulnerability databases" (+ a socket.dev option via --socket), and the package-manager migration docs say "npm advisory database." An assertion like "Deno uses OSV" is not confirmed by official sources. What I can say empirically from my experiment goes only as far as the fact that "both surfaced the same GHSA identifiers."

On top of that, even with the same package.json, if npm and Deno installed using different lockfiles (package-lock.json vs. deno.lock), the dependency graph being inspected could be subtly different in the first place. In that case the difference in audit results isn't a "false positive" but the result of inspecting a different graph. deno audit --fix, like npm, automatically bumps vulnerable direct dependencies within the SemVer-compatible range, but conservatively leaves major upgrades and transitive dependencies untouched (deno audit docs).

Scene 5 — `pack`: this one actually wasn't the same kind of tool

Here I ran into the biggest misconception. At first I tried to compare npm pack and deno pack side by side on the same package.json project, but after reading the official docs I had to change my experiment design. The deno pack docs nail it down — deno pack is not equivalent to npm pack. It doesn't even read your existing package.json, and it doesn't honor .npmignore or lifecycle scripts.

So I ran the two each according to its own role. npm pack on a plain package.json project, and deno pack on a deno.json-based TypeScript project.

# npm pack — compresses the source as-is (no transformation)
package/index.js
package/test.js
package/package.json        (4 files, 944B)

# deno pack — from a single mod.ts...
package/package.json   <- "synthesized" from deno.json metadata
package/mod.js         <- TS "transpiled" to JS
package/mod.d.ts       <- type declarations "generated"        (680B)

The results reveal the essence. npm pack is a compressor — it puts the files you currently have into a tarball as-is. deno pack is a distribution transpiler — it turns .ts into .js, generates .d.ts type declarations, and synthesizes a package.json from deno.json, converting it into a bundle that npm consumers can understand. One "packages the npm package you already have," the other "ushers code from the Deno/JSR world through customs into the npm world."

So the sentence "deno pack swallowed npm pack" is wrong. More precisely: deno pack didn't replace npm's packing — it's a different category of tool that automates the customs process of exporting a library written in Deno/JSR to npm. The docs even honestly note the limits — bin entries for CLIs, and native add-ons, are out of scope.

On the side — how far does runtime compatibility go?

Separate from the package-manager discussion, I ran the same index.js (code that loads Node built-ins fs, path, crypto, and os plus lodash, minimist, and chalk via CommonJS) under both node and deno run. The output was byte-for-byte identical — the sha256 hash, the lodash results, and chalk's ANSI colors were all the same, with the only difference being argv0 (node.exe vs. deno.exe). Deno also passed all seven of the trickier built-ins (child_process, worker_threads, cluster, v8.serialize, vm, process.binding, os.cpus) in a CommonJS context.

The "76.4% Node compatibility" the Deno 2.8 blog touts roughly matches this experience, but you mustn't misread the number.

[!NOTE]
76.4% is relative to Node.js's own test suite (3,405 of 4,457 passing), not the JS language standard (test262) and not a claim that "76% of real projects run." If the API or build tool you use is in the remaining ~24%, that project breaks. Test pass rate and project compatibility are different axes.

In fact I directly saw the boundary of compatibility in two places.

require is context-sensitive. For a bare .js file outside a package.json (type: commonjs), Deno treated it as ESM and threw require is not defined. Node is more lenient. It's a porting trap that's sensitive to file location and the type field.
Lifecycle scripts don't run by default. When I set a postinstall at the root and installed, npm install ran the script (creating POSTINSTALL_RAN.txt) but deno install did not. This is double-edged — it's a security advantage that blocks postinstall, a frequent vector for supply-chain attacks, by default, but at the same time it's a trap that breaks packages relying on node-gyp builds or postinstall (e.g., some native add-ons).

At a glance — where in the npm toolchain did Deno 2.8 land?

📊 The decision-flow diagram for this section renders in the original article on var.gg →

An honest verdict table on replaceability

Question	Verdict	Why
Does `deno install` replace `npm install`?	Partially yes	It reads `package.json`, pulls from the npm registry, and builds `node_modules`. But it uses a separate `deno.lock`, and as of 2.8 it neither reads nor writes `package-lock.json`.
Does `deno ci` replace `npm ci`?	Yes, if you adopt `deno.lock`	Both fail on a lockfile mismatch, delete `node_modules`, and do a frozen install. Only the reference lockfile differs.
Does `deno audit` replace `npm audit`?	Detection is comparable, policy differs	It surfaces the same GHSAs but differs in counting unit, autofix scope, and JSON/signature-verification features.
Does `deno pack` replace `npm pack`?	Mostly no (different category)	The official docs explicitly say it's "not equivalent." It's a Deno/JSR → npm converter.
Does `deno run` replace `node`?	Pure JS/npm is worth experimenting with, but not everything	Claims 76.4% Node test pass rate. Native add-ons, postinstall, and layout-dependent tools are the boundary.

So who else is being compared against npm?

Deno isn't the only one eyeing npm's job. pnpm, Yarn, and Bun have long competed for the same spot.

Tool	Install structure	CI reproducibility	Built-in audit	pack/publish	One-line take
npm	flat `node_modules` (ecosystem baseline)	`npm ci` (lock required)	`audit` / `audit fix` / `audit signatures`	`npm pack` / `publish` standard	Can be slow, but it's the baseline. Strongest publish compatibility
pnpm	content-addressable + hardlink (disk savings)	frozen-lockfile by default, `pnpm ci` (11.x)	`pnpm audit`, signing supported	`pnpm pack` / publish	Strong for large monorepos and strict dependencies
Yarn Berry	PnP by default (`.pnp.cjs`, no `node_modules`)	`--immutable` (CI default)	`yarn npm audit`	`yarn npm publish`	Zero-install philosophy. Migrating existing projects needs care
Bun	fast manager + runtime (`bun.lock`)	`--frozen-lockfile`	`bun audit`	`bun pm pack` (follows npm pack rules)	Strong on speed and all-in-one. Full Node compat needs separate checking
Deno 2.8	global cache + isolated/hoisted linker	`deno ci` (`deno.lock`)	`deno audit` / `--fix` / `--socket`	`deno pack` (JSR→npm conversion, npm pack ≠)	install/ci/audit are worth experimenting with; pack is a different category

So when is it worth swapping in?

Worth trying: small services with mostly pure JS/TS dependencies, no native add-ons or complex workspaces. When you want to keep the runtime on Node and just swap install and audit to Deno for speed. When you want to block postinstall by default for security. Authors who want to also distribute a Deno/JSR library to npm (this matches the original purpose of deno pack exactly).
Be cautious: native add-on dependencies (which need a local node_modules, --allow-ffi, and approved scripts), complex bundler/plugin toolchains that assume a flat layout, large monorepos using pnpm-workspace.yaml (2.8 doesn't read this file), Yarn PnP projects, and organizations bound to the npm publish lifecycle or npm audit signatures compliance.

Honest conclusion

The opening 2 vs. 7 wasn't a sign that Deno was wrong or that npm was wrong, but that the two tools stand in the same territory and work by slightly different rules. The five scenes of this article revealed those rules one by one.

Deno 2.8 has not "fully replaced" npm. But for install, ci, and audit, it has now reached a level where you can seriously consider swapping it in on the same package.json project — faster cold installs, an isolation layout that blocks phantom dependencies, friendlier lockfile diffs, and an audit that sees the same GHSAs. On the other hand, pack is not a replacement for npm pack but a bridge that exports Deno/JSR to npm, and run's full Node compatibility remains a per-project thing to verify.

If you smudge over this difference and write "Deno 2.8 swallowed the npm workflow whole," you get a marketing piece. If you surface the difference and split it into "this part is a replacement, that part is a different category," you get a technical piece. The most honest way to evaluate a new tool is always the same — don't trust the slogans; run it yourself on the same fixture. It's the very attitude we confirmed in the case of Vite 8, where a framework was swallowing its build tool as a built-in.

Experiment environment: Windows 11 x64 · Node v24.15.0 / npm 11.12.1 · Deno 2.8.0. The fixture was composed of lodash@4.17.15, minimist@1.2.5, and chalk@4.1.2 (intentionally vulnerable versions for the audit comparison), and all numbers are local measurements from 2026-06-26. lockfile seed behavior may differ on Deno 2.9 and later.

How to Create a Custom Cloudflare API Token (2026 Guide)

curioustore — Sat, 27 Jun 2026 22:13:34 +0000

Cloudflare's template tokens (Edit zone DNS, Workers AI, etc.) are the fastest path, but most of them are over-permissioned. A leaked token with too many scopes causes a lot more damage than one that can only do exactly what your app needs.

This guide shows the generic Custom Token flow that works for any resource — R2 uploads, DNS automation, Workers deployments, cache purging, and more. We'll cover the minimum-permission mapping for the most common use cases in Step 04.

Step 01 — Click 'Create Token' on the API Tokens page

Start here: dash.cloudflare.com/profile/api-tokens

From the Cloudflare dashboard, click the profile icon in the top-right to land on this page, then click the + Create Token button in the top right.

[!TIP]
User API Tokens vs. Account API Tokens: tokens created on this screen are scoped to your user. For CI/CD or shared team services, Cloudflare recommends Account API Tokens (created from the account-level admin area) so the token survives a person leaving. For personal automation scripts, user tokens are simpler.

Step 02 — Click 'Get started' under Custom token

On the template selection page, click Get started next to Create Custom Token at the top. Everything below is a preconfigured template, but templates are usually broader than what you actually need.

Step 03 — Enter a token name

Give the token a name that tells future-you where it's used. When a token starts misbehaving months from now, the name is the only cue in the token list and in audit logs.

Recommended naming pattern: {project}-{purpose}-{environment}. Examples:

myapp-r2-uploader-prod
myapp-dns-updater-dev
cicd-workers-deploy

Step 04 — Choose permissions (scope → resource → level)

Permissions are built from three dropdowns:

Scope — Account, Zone, or User
Resource — e.g. Workers R2 Storage, Zone DNS, Cloudflare Workers Scripts
Level — Read or Edit

Minimum permissions by use case:

Use case	Scope	Resource	Level
Upload to an R2 bucket	Account	Workers R2 Storage	Edit
Automate DNS records	Zone	DNS	Edit
Deploy Workers (wrangler)	Account	Cloudflare Workers Scripts	Edit
Purge cache only	Zone	Cache Purge	Edit
Read analytics	Account	Account Analytics	Read

[!TIP]
+ Add more lets you stack multiple rows, but stuffing many purposes into one token makes rotation painful. One token, one purpose is usually the right default.

The sections below — Account Resources / Zone Resources / Client IP Address Filtering / TTL — are worth restricting too. If your deploy server has a static IP, Client IP Address Filtering dramatically limits the blast radius if the token ever leaks.

Step 05 — Click 'Continue to summary'

Once permissions are set, click Continue to summary at the bottom of the page to review.

On the review page, clicking the final Create Token button displays the token string exactly once. Closing that screen loses the token forever.

[!WARNING]
Copy the token immediately to a safe place. A password vault (1Password, Bitwarden) or your CI secrets manager is the right destination. If you suspect a leak, roll it right away from the token list page — the ... menu has a Roll option.

Common mistakes

Picking a template because it's "faster": most templates are over-permissioned. Edit zone DNS grants zone-wide DNS write for a token that's supposed to do R2. Custom feels slow the first time, but it's faster in the long run.
Closing the final screen without copying: the only recovery is to recreate the token.
Leaving TTL at No expiration: the default is unlimited. Set an End Date at creation time or put a quarterly rotation reminder on your calendar.
Leaving IP filtering on while testing locally: your home/café IP changes. Use IP filtering only for deploy environments and keep a separate token for local use.
Sharing one token across teammates: you lose per-person audit trails. Each person issues their own, or set up a service account with its own token.

References

Cloudflare docs: Create API token
Cloudflare docs: API token permissions
Cloudflare R2: Authentication — for R2 use cases
Cloudflare Workers CI/CD — for deploy automation

Last verified: 2026-04-17 · English UI · Re-verified quarterly for drift

Google Cloud OAuth Consent Screen + OAuth Client ID (2026 New UI)

curioustore — Sat, 27 Jun 2026 22:13:33 +0000

Google Cloud OAuth Consent Screen + OAuth Client ID (2026 New UI)

[!NOTE]
TL;DR: 2025–2026 Google Cloud Console was reorganized into the Google Auth Platform (Branding / Audience / Data Access / Clients), and the path to set up an OAuth consent screen changed completely. This guide walks from a fresh project to a Web Client ID/Secret in 7 steps, ~10 minutes. The two things that actually matter: picking [External] in the wizard and getting the redirect URI exactly right.

Why this guide exists

Most existing English guides still describe the old UI and send readers chasing menus that no longer exist.
The new UI starts with a "Get started" wizard — a single page with 4 stepper sections, not the old multi-screen flow.
Pick External vs. Internal wrong and a regular web app will not work. The wizard does not let you change it later — you'd need a fresh project.

Prerequisites

A Google account
Access to a GCP project (or create one in step 01)
Billing not required — OAuth consent screen + Client ID setup are free

Step 01 — Create a new GCP project

Start here: console.cloud.google.com/projectcreate

From the top-left project selector → "New project", or open the URL directly. Pick a recognizable name. The project ID is globally unique, so a numeric suffix may be appended automatically. Linking a billing account is NOT required for OAuth consent screen setup — skip the prompt if it appears.

Don't forget to switch to the new project from the selector after creating it. Otherwise the next steps will configure OAuth on a different project.

Step 02 — Open the OAuth consent screen → [Get started]

Start here: console.cloud.google.com/auth/branding?project=YOUR_PROJECT_ID

A fresh project shows the "Google Auth Platform not configured yet" notice. Click [Get started] at the bottom right to enter the 4-step wizard.

Three ways to land here (any of them works):

Left hamburger menu → APIs & Services → OAuth consent screen
Top search bar → type OAuth → click the result
Open the URL above directly

Step 03 — Pick [External] in the wizard (most common mistake)

Start here: console.cloud.google.com/auth/overview/create?project=YOUR_PROJECT_ID

The wizard is a single page with 4 stepper sections (1 → 2 → 3 → 4):

App Information — App name (shown on the consent screen), User support email (dropdown of your Google accounts)
Audience (User Type) — ⚠ the only real decision
Contact Information — Email Google uses for policy/notification updates
Finish — Accept the policy → [Create]

External vs. Internal — pick once, can't change later (without a fresh project):

Option	Who can sign in?	When to pick?
Internal	Only accounts in the same Google Workspace organization	Internal tools (org account required)
External	Anyone with a Google Account	Public web apps (starts in test mode)

For a typical web app, always pick [External]. External starts in "test mode" — only test users you add in step 04 can sign in until you publish the app.

Step 04 — [Audience] tab — add test users

Start here: console.cloud.google.com/auth/audience?project=YOUR_PROJECT_ID

An External-type OAuth app starts in "Testing" mode. Only Google accounts on the [Test users] list can sign in — everyone else hits an access_blocked error (the actual face of "Error 403: access_denied" you've probably seen elsewhere).

Click [Add users] and register your own + teammate/QA emails (up to 100). Effective immediately.

After publishing to production anyone can sign in, but:

Non-sensitive scopes (openid/email/profile) → publish freely
Sensitive scopes (Drive/Gmail/Calendar etc.) → Google verification process (weeks, security review)

Step 05 — [Data access] tab — add OAuth scopes

Start here: console.cloud.google.com/auth/scopes?project=YOUR_PROJECT_ID

Define the scopes (permissions) shown to users on the consent screen.

For typical Google Sign-In, three are enough (all non-sensitive):

openid
.../auth/userinfo.email
.../auth/userinfo.profile

Click [Add or remove scopes] → check the three in the right panel → [Update].

Scope category	What it accesses	Google verification
Non-sensitive	Basic identity (email, profile)	Not required
Sensitive	Some Drive/Gmail/Calendar	Required
Restricted	Full Gmail/Drive	Required + security assessment

Step 06 — Web client + Authorized redirect URIs

Start here: console.cloud.google.com/auth/clients/create?project=YOUR_PROJECT_ID

[Clients] tab → [Create Client] to get here.

Form fields:

Application type: Web application for any browser-initiated OAuth flow (including BE servers exchanging tokens)
Name: just a label (e.g., myapp-web-prod, myapp-web-dev)
Authorized JavaScript origins: only needed for SPAs (browser-only token retrieval). Leave blank if your BE handles it
Authorized redirect URIs: the exact callback URL ⚠

A single character mismatch in the redirect URI yields redirect_uri_mismatch. Common slip-ups:

http:// vs. https://
Trailing slash (/callback vs. /callback/)
Port (:3000 present or not)
Missing dev/staging/prod URIs

http://localhost:3000/... works for local dev. Multiple URIs allowed on the same client.

Then [Create].

Step 07 — Save Client ID + Secret (Secret won't be shown again)

Right after [Create], the OAuth client created dialog appears.

Credential	Public OK?
Client ID (`123-abc.apps.googleusercontent.com`)	✓ Public OK (the identifier visible in browsers)
Client Secret (`GOCSPX-...`)	✗ Never expose

Once the dialog closes, the Secret is never shown again. You'd need to issue a new secret or recreate the client.

Click [Download JSON] and:

Move it to .env or a password manager (1Password, Bitwarden, etc.) immediately
Never commit to Git — add *.env, client_secret*.json to .gitignore
Delete the downloaded JSON file from disk after saving

If exposed, rotate immediately: [Clients] tab → the client → "Add/Revoke secret" to issue a new one and expire the old.

Common mistakes

Picked Internal → web app only accepts org accounts. You'd need a fresh project (External isn't reachable later).
Forgot to register test users → you can sign in but teammates/QA hit access_blocked.
Redirect URI off by a character → redirect_uri_mismatch. Register every environment URI.
Hardcoded Client Secret in source instead of .env → exposed on Git push. Use a pre-commit hook (gitleaks, detect-secrets) to block it.
Adding sensitive scopes and trying to publish without verification → Google verification required. Ship the first version with non-sensitive scopes (openid/email/profile) only.
Navigating away mid-wizard → wizard ends in an incomplete state. Start over from step 02.
Picked iOS/Android/Desktop instead of Web Application → wrong OAuth flow, won't fit your BE server code.

References

Written against the 2026-04-18 Google Cloud Console UI. The UI may shift again — substitute your own project ID into the URLs above when following along.

The agent writes the code now — what should a git tool be?

curioustore — Sat, 27 Jun 2026 18:42:27 +0000

For years I ran VS Code as a git client. Not really an editor — a GitLens host. The branch graph, the heat-mapped blame, the inline lens annotations: that was my git workflow.

Then 2025 happened, and that workflow quietly fell apart. Somewhere in there I realized git tools had been built for the wrong person all along.

GitLens kept me tied to the editor

GitLens is a great extension. Every commit annotated next to the code, a file's history as a heat map, the branch graph on a single screen. I used it for years.

The catch is that GitLens only lives inside the editor. To look at commit history, VS Code has to be open. For a long time that wasn't a cost — I was in the editor all day anyway. I was the one typing the code.

2025: my hands left the keyboard

Then Cursor, Claude Code, and Codex showed up. At first it felt like autocomplete with a longer reach. Then I looked up and the agent was doing the actual editing — writing functions, refactoring across files, even making the commits. I direct, I read, I judge.

The role flipped. I'm not the author of the code anymore so much as its reviewer. I spend more time looking at what the agent just did than with my hands on the keys.

And at that point VS Code started to feel like overhead. The agent runs in a terminal. I had no reason to keep an editor open — except one: GitLens. Booting an entire IDE just to glance at a list of commits suddenly looked absurd.

Git tools are still built for the author

Here is the real problem. Almost every git tool — GitLens, Sourcetree, GitHub Desktop, lazygit, the editor's built-in SCM panel — assumes a person who writes the code by hand.

So they put commit, stage, push, merge, rebase, and cherry-pick front and center. They go deep on blame. They pour effort into conflict-resolution UI. All of it is what an author needs.

But in the agent era my git usage looks different. Most of the time I am just:

seeing what the agent just committed
deciding whether it makes sense
expanding the diff when something looks off
telling the agent to redo it when it is wrong

Nowhere in that loop do I commit, push, or merge by hand. If git surgery is needed, it is faster to tell the agent in words. Yet the existing tools spend their screen space and their weight on exactly the surgery features I now barely touch.

The tools are not wrong. The user they were designed for is just from an earlier era.

What a git tool for the reviewer looks like

So what should a git tool for the reviewer be? I landed on four things.

1. It should be read-only. A tool whose job is verification should not be able to change state by accident. If there is no commit/push/merge button, there is no button to hit by mistake. Read-only is not a missing feature — it is a design decision.

2. It should be resident, not a window. Reviewing is a short action that happens dozens of times a day. Launching and closing an app each time is friction. Better to sit in the tray, expand on a single click, and get out of the way.

3. It should be done in half a second. "Did the agent just do that right?" is a half-second question. If the tool takes longer than that, people simply skip the check. For a glance, speed is the feature.

4. It should not try to be where you fix things — it should hand off to the agent. When something is wrong, the tool does not need to let you fix it in place. Bundle the commit and the diff into clean context and hand it straight to the agent. The agent is better at the fix.

So I built gitwink

gitwink is those four things, built.

gitwink lives in your system tray. Click it — or hit Ctrl+Shift+G — and a panel expands with the recent commits across all of your local repos on one timeline. Filter by repo, time range, or author; click a commit and the message body and changed-file list expand inline.

For the "wait, did the agent actually do that?" moments, a separate diff window opens a side-by-side view — with before/after preview for image assets.

And the key part: Copy as AI context. One press of c and the commit, the file list, and the diff land on your clipboard as a markdown block. Paste it into Claude or Codex and ask "is this right?". The tool does not take the seat of judgment — it just hands over clean material to judge.

gitwink is not a git client. It cannot commit, push, or merge. It is read-only by design. No telemetry, no phone-home, no network calls — it is a small local app built with Tauri 2 and Rust, and the code is MIT.

Windows and macOS builds are on the latest release. (The artefacts are not code-signed yet, so SmartScreen / Gatekeeper will warn on first launch — the release notes have the bypass steps.)

Wrapping up

As agents started writing the code, a developer's job shifted from authoring to reviewing. But most git tools are still designed for the author. A reviewer needs something that is read-only, resident, fast, and able to hand off to the agent. gitwink is the smallest version of that idea I could build.

gitwink — a read-only tray git glance for the AI-agent era

curioustore — Thu, 28 May 2026 01:32:05 +0000

I used to live in VS Code with GitLens pinned — the branch graph, heat-mapped blame, the lens annotations. That was my git workflow.

Then 2026 happened. With Cursor, Claude Code, and Codex doing the actual editing, the editor itself became optional. The only thing dragging me back was GitLens.

That felt wasteful — booting an entire IDE just to peek at commit history. The agent runs the git commands now; I only need to sanity-check the result, occasionally, when something looks off.

So I built gitwink — the smallest possible tool for that loop. A tray icon that expands into a glance, hands the commit off as AI context, and gets out of the way.

Read-only by design. It cannot commit, push, merge, or modify anything. If I need git surgery, I tell the agent.

The 0.5-second confirm loop

agent commits  →  tray click  →  inline expand  →  "Copy as AI context"
                                                  →  paste into Claude/Codex/Cursor
                                                  →  "did the agent do this right?"

No window switching. No IDE boot. The whole loop fits inside a glance.

What's in it

Tray-resident (Windows tray / macOS menu bar) — click to toggle, global hotkey Ctrl+Shift+G to summon from anywhere. Right-click the tray icon for Reset position / Open settings file / Quit.
First-run discovery that walks your usual code dirs (source, Documents, Projects, Code, Dev, repos, Desktop, every non-system drive on Windows; ~/Projects, ~/Code, ~/Developer on macOS) and caches the result in SQLite. No "add repo" friction.
Unified commit timeline across all repos, with chips above for filtering by Repo (search + pinning), Time range (24h / 3d / 7d / 30d / All), and Authors (multi-select with counts). Per-row markers — ● commit · ◆ merge · ★ tagged — and branch label badges when a commit isn't on the currently checked-out branch.
Single-repo DAG view — pick a repo and the panel switches to a per-branch graph with a custom SVG lane drawer (eight-colour palette, hashed from branch name; main / master / develop kept neutral).
Inline expand on click — commit body + changed-file list with NEW/MOD/REN/DEL badges, +/− line counts, bin + size for binaries, GitLens-style filename emphasis.
Separate diff window for the full read — file sidebar + side-by-side diff with synchronised horizontal scroll, PNG / JPG / GIF / WebP / SVG image preview (before / after, with checker background). Singleton, remembers position, size, and maximised state. Local Git LFS objects are looked up automatically; missing ones are explained inline.
Copy as AI context — c key or button. Produces a markdown block with the commit, file list, and (if small enough) the full diff, ready to paste into Claude / Codex / Cursor.

The diff window

For the "wait, did the agent actually do that?" moments. Click any commit and a separate window opens — full file sidebar, side-by-side diff with synchronised scroll, inline image preview for binary assets, and a singleton that remembers position, size, and maximised state.

Stack

Tauri 2 — Rust core, web frontend, native tray
Rust + git2 for the git plumbing
React + TypeScript for the panel
SQLite for the repo discovery cache
Custom SVG DAG drawer (eight-colour palette, hashed from branch name)

No telemetry. No phone-home. The only network access is an opt-out update check.

Get it

Microsoft Store — gitwink on the Microsoft Store →. The Store build is signed by Microsoft during certification, so no SmartScreen prompt appears, and the Store owns updates.

WinGet:

winget install gitwink

Scoop:

scoop bucket add var-gg https://github.com/var-gg/scoop-bucket
scoop install gitwink

Scoop installs by extraction, so no SmartScreen prompt either. Update later with scoop update gitwink.

Or grab the release directly — latest release on GitHub:

Windows — .exe (NSIS installer) or .msi
macOS — .dmg (universal)

Direct downloads are currently unsigned (gitwink participates in the SignPath Foundation free code-signing program for OSS; the certificate will sign these artefacts once approved). The release notes have the SmartScreen / Gatekeeper bypass steps.

Building from source is straightforward — pnpm install && pnpm tauri dev. Requires Node 20+, Rust stable (msvc toolchain on Windows), Visual C++ Build Tools or Xcode CLT.

Status

v0.4 — usable, daily-driven. Cold-start friendly tray app.

Windows 10/11 — primary target, tested on dev hardware
macOS 13+ — should work, less battle-tested
Linux — later

Source on GitHub → (MIT licensed)

If the AI-agent workflow describes your week too, give it a wink. Feedback and issues welcome on GitHub.

DEV Community: curioustore

Vercel AI SDK 6: An Agent Is Just a while Loop

What does the AI SDK actually do for you

What an "agent" really is: the while loop that stopWhen turns on

When the loop hits an error: it doesn't die, it snitches to the model

The type boundary of structured output: compile time and runtime are different layers

Streaming is a procession of typed parts

The quiet v5 → v6 trap: the vanished maxSteps

What it gives you, and what it doesn't

But why is the "mock model" the crux?

Measured against the alternatives

When to reach for it, and what to remember

uv audit vs pip-audit, and a gate narrower than it looks

First, let's separate two features that look alike

Running uv audit myself

Not for humans — machine-readable output

Silencing the noise, and the trap in it

Side by side with pip-audit: same answer, different speed

The side that blocks installs: the malicious-package gate

A boundary narrower than expected

So how does it sit next to other tools

So should you turn it on now

In closing

Vite 8's Rolldown Makes Builds 13x Faster, Not the Dev Server

So what is Vite, and why did it have two engines?

What changed — pinning down "old X → new Y" exactly

I ran it myself — packages vanished, the build got 13× faster

(1) Two engines collapse into one binary

(2) The build got ~13× faster (stable across repeated runs)

(3) The 13× isn't the result of skipping work

Is "10–30×" real? Only if you keep the conditions attached

So does anything break? "Mostly works" isn't "works without checking"

Should you migrate now? Conclusions by situation

Wrapping up — not "fast because Rust" but "the internal contract changed"

Node.js 26 Enables Temporal by Default — Time to Ditch Date?

What happened — Node 26 just "turned Temporal on"

Wait, what is Temporal?

Why Date has taken 30 years of flak

The real trap is time zones

Calendar arithmetic: refusing instead of quietly getting it wrong

So can you ditch Date? — an honest look at the limits

Things to check before upgrading to Node 26

Wrapping up — when to use Temporal

I Ran TypeScript 7's Native Compiler (tsgo) on Our Monorepo

TL;DR

The paradox of TypeScript being written in TypeScript

Why Go and not Rust — "porting," not "rewriting"

TypeScript 6.0 as a bridge

I ran it on our own monorepo

Speed

And the two compilers did not report the same errors

Where does 10x come from, and why was it 3x for us

What tsgo doesn't give you yet

So what to do now

Conclusion — not a swap, but being ready to measure for yourself

Python 3.15's UTF-8 Default (PEP 686): I Verified the Silent Byte Changes on Windows

Before we begin: encoding as a "translation dictionary"

Exactly what changes — the defaults I measured directly

Same program, different bytes

Distinguishing the three layers

Why now — nine years in the making

"Silent breakage" — more dangerous than an error

Common Hangul fails loudly (the lucky case)

But some bytes silently become different characters

Where it's costlier and surfaces later: writes and appends

subprocess: when you capture the tool next door

The safety net is "explicit," not "automatic"

The precise meaning of encoding="locale"

Toggles and precedence

Migration priorities

Closing — the direction is right, but the lesson is the opposite

References (official docs)

Did Deno 2.8 Swallow the npm Toolchain? I Ran install, ci, audit, and pack Myself

First, just five terms — let's start with "what these are"

Scene 1 — install: same downloads, but faster, and stacked differently

Scene 2 — phantom dependency: the same code worked on one side and failed on the other

Scene 3 — ci: both "stop if you break the seal," but their tone differs

Scene 4 — audit: the truth behind 2 vs. 7

Scene 5 — pack: this one actually wasn't the same kind of tool

On the side — how far does runtime compatibility go?

Running `uv audit` myself

Side by side with `pip-audit`: same answer, different speed

The precise meaning of `encoding="locale"`

Scene 1 — `install`: same downloads, but faster, and stacked differently

Scene 3 — `ci`: both "stop if you break the seal," but their tone differs

Scene 4 — `audit`: the truth behind 2 vs. 7

Scene 5 — `pack`: this one actually wasn't the same kind of tool