import { cloudflare } from '@cloudflare/vite-plugin'

export default defineConfig({
  plugins: [cloudflare({ viteEnvironment: { name: 'ssr' } }), tanstackStart(), viteReact()],
})

That matches the documentation. When the same app is deployed with Alchemy, the build fails during prerendering.

The failure

[prerender] Prerendering pages...
[prerender] Crawling: /
Error: Server is not running.
    at disposeMiniflare (@cloudflare/vite-plugin/dist/index.mjs)
    at prerender (@tanstack/start-plugin-core/dist/esm/prerender.js)

vite build locally succeeds. Only the deploy fails, and it fails inside prerendering.

Why

Alchemy's Website.Vite resource does not shell out to vite build. It builds in process, and it constructs the builder with its own plugin list:

const builder = await vite.createBuilder({
  plugins: [cloudflare(pluginOptions), outputPlugin.plugin],
})

Alchemy adds cloudflare() because it needs control over the Worker environment it is about to deploy. When the app config registers it too, the build runs with two instances of the Cloudflare plugin, and therefore two miniflare servers.

TanStack Start's prerenderer boots a server and requests every page through it. One of the two plugin instances finishes its own lifecycle and disposes its miniflare while the prerenderer is still rendering through the other. The server the prerenderer was using goes away mid crawl, which produces Server is not running.

The fix

Remove the Cloudflare plugin from the app config and let Alchemy supply it:

export default defineConfig({
  plugins: [tanstackStart({ prerender: { enabled: true } }), viteReact()],
})

Two consequences follow from that.

Local vite build changes shape. Without the plugin, prerendering runs in plain Node instead of workerd. Anything imported during prerender that expects the Worker environment, such as bindings or .dev.vars secrets, now fails locally while continuing to work under Alchemy. In my case better-auth started throwing on a missing BETTER_AUTH_SECRET, which miniflare had been supplying from .dev.vars.

npm build scripts do not run on deploy. Alchemy calls Vite's API directly, so "build": "node scripts/generate-feed.mjs && vite build" does not generate the feed when Alchemy builds. Work that has to happen on every build belongs in vite.config.ts as a plugin rather than in package.json.

Which plugins belong where

When a deploy tool builds the app, it owns the build pipeline. Plugins that shape the output target, the Cloudflare plugin here, belong to whoever is doing the deploying. Plugins that shape the application stay in the app config.

Both sets of docs are accurate on their own. TanStack documents the plugin because the target needs it, and Alchemy does not mention removing it because it provides one itself. The combination is where the ownership question comes up, and the first signal is the disposal error during prerender.

Why it happens

The preview renders markdown, but search ran against the raw markdown source. Syntax that never becomes visible text was still searchable:

• Link destinations. In [label](url), only label renders, but url was still matched
• Images, including both alt text and destination
• Link reference definitions, which pulldown-cmark consumes without emitting any event

Badge heavy READMEs show it most clearly, since every badge URL contributes words like github, build, main, and svg that never reach the screen.

The fix

Track which source ranges produce no on-screen text, then filter matches against them. The ranges are returned sorted and disjoint, so the preview can binary search rather than scan.

A second issue sat underneath. Search results derive from the parsed markdown, and the parse happens in the background, so results could be computed against a stale parse. MatchesInvalidated now fires once the parse lands.

Testing

Eight new tests cover link destinations, reference definitions, standalone images, linked images, images between link text, parse in flight, and match order independence.

Merged as zed-industries/zed#62280.

tanstackStart({
  prerender: {
    enabled: true,
    filter: (page) => !page.path.startsWith('/api'),
  },
  sitemap: { enabled: true, host: 'https://example.com' },
})

Every page filtered out of prerendering is still in sitemap.xml.

Where each list comes from

The sitemap builder does not look at prerender results. It builds from the discovered pages list, and the only thing that removes an entry is a per-page flag:

pages.filter((page) => page.sitemap?.exclude !== true)

prerender.filter and sitemap.exclude are two independent gates, so a page can be skipped by the renderer and still advertised to crawlers as something that exists.

Two cases from this site

A duplicate URL. With autoStaticPathsDiscovery on, route based discovery contributed /blog/ while link crawling contributed /blog. That is one document with two sitemap entries, one of which 307 redirects to the other. Filtering the trailing slash form out of prerendering changed nothing in the sitemap. Turning auto discovery off left link crawling to produce one canonical form per page.

The RSS feed. Adding <a href="/rss.xml">rss</a> to the footer meant the crawler discovered the feed as a page. Excluding it from prerendering was not enough, since /rss.xml still appeared in the sitemap as an indexable URL. That case needs the flag:

pages: [
  { path: '/' },
  { path: '/rss.xml', sitemap: { exclude: true } },
],

Declaring pages replaces the discovery seed

Declaring pages replaces the discovery seed rather than adding to it. My first attempt listed only /rss.xml, and the build prerendered zero pages and wrote an empty sitemap. / has to be listed explicitly so link crawling still has somewhere to start.

Checking the generated file

The build log said Prerendered 11 pages in every one of these states, and that was accurate. The difference was in a file the log does not mention, so it is worth reading the generated XML directly:

grep -o '<loc>[^<]*</loc>' dist/client/sitemap.xml

Every URL in there should return 200 rather than a redirect, and should be a page you want indexed.

The mechanism

Sitemap discovery happens at the host root. Google fetches example.com/robots.txt and reads the Sitemap: directive there.

example.com/robots.txt is not served by the Worker. It is served by whatever owns the root of the domain, in our case the main marketing site. The framework emits its sitemap relative to its own base, so it lands at example.com/google/sitemap.xml, and nothing at the root points to it. The sitemap exists and is valid, and no crawler finds it.

What the framework can and cannot do

An app mounted under a path does not own the domain root. It can generate a correct sitemap and still have no way to advertise it, because the file that does the advertising belongs to a different app.

Options

Moving to a subdomain resolves it structurally. On warya.example.com the app owns its own root, so robots.txt and sitemap.xml sit exactly where crawlers look for them.

It is also fixable in place. A Sitemap: line in the root robots.txt can point at a sub-path sitemap, and Search Console accepts a manual submission. Both require editing the root, which is the part outside the app's control.

Checking it

Fetch yourdomain.com/robots.txt and check whether it names a sitemap the app actually serves.

The fix was one line. Finding it meant following the request through three tools, each of which was doing what it was designed to do.

The loop

1. The browser requests /example/pricing
2. Vite's base middleware rewrites req.url to /pricing, by design, so internal middleware sees paths without the base
3. The Cloudflare dev plugin forwards /pricing to the Worker
4. TanStack Start sees a URL missing its base and redirects to /example/pricing
5. Back to step 1

Following the redirects exhausted the browser's redirect limit. Every path 307'd to itself.

Where the base is lost

Vite strips the base deliberately, since its middleware pipeline is meant to work in base-relative terms. TanStack Start redirects deliberately, since a URL missing its configured base should be corrected. The Cloudflare plugin forwards what it is given.

The gap is in the handoff. Vite preserves the browser-facing URL on req.originalUrl precisely so that middleware needing the real URL can recover it. The dev plugin was not reading it:

const url = new URL(req.url ?? "/", address);

So the Worker received a different pathname in development than the browser had requested.

The fix

const url = new URL(req.originalUrl ?? req.url ?? "/", address);

/example/pricing?plan=pro now reaches the Worker unchanged, base path and query string intact, with the existing fallback preserved.

Cloudflare's own Vite plugin already restores req.originalUrl before constructing the Worker request, for the same reason. The fix aligns this plugin with that behaviour rather than introducing anything new.

Validating it

Before, against the unmodified plugin: /example/ returned 307 Location: /example/, and /example/pricing returned 307 Location: /example/pricing. Both self-redirects.

After: / returns 302 Location: /example/, /example/ returns 200, and /example/pricing returns 200.

Where these bugs live

When requests loop between tools, the cause is often at a boundary rather than inside any one of them, in an assumption one side makes about what the other preserves. req.url versus req.originalUrl is a distinction that only surfaces once an app is mounted somewhere other than the root.

Merged as alchemy-run/cloudflare-tools#86.

This change reports URL hovers from the markdown renderer and displays the hovered destination with the existing LinkPreview component in the bottom-left corner, the same position browsers use.

Hit detection for linked images

Text links are straightforward. The text layout already knows what is under the pointer.

Linked images are not. An image sits outside the text layout, so that hit detection does not see it, and it needs its own path. This is the same structural detail behind making linked images clickable: nested images live outside the system that handles the rest of the content.

Clearing the preview

The other half of the work is clearing the indicator so it never shows a stale URL. It clears when the pointer leaves a link, when it leaves the preview entirely, and when the displayed markdown changes. That last case covers scrolling or re-rendering while a link is hovered.

Test plan

The test plan covers the disappearing cases alongside the appearing ones: moving away from a link, moving outside the preview, and changing the document.

Merged as zed-industries/zed#60942.

Cause

The renderer handled <a> tags and it handled <img> tags. It did not handle an <img> nested inside an <a>. The image drew itself and the surrounding link never got a chance to make it interactive.

The fix

The nesting is detected during render. For a linked image, the wrapper div gets cursor_pointer and an on_click handler that opens the URL, or delegates to the on_url_click callback when one is set. The wrapper also captures right clicks so "Copy Link" appears in the context menu.

Two details went beyond the nesting check:

The callback had to become cloneable. on_url_click was a Box<dyn Fn>, which a single handler can own. Multiple handlers need it now, so it became an Rc<dyn Fn>.

Broken images opened the URL twice. When an image fails to load, a fallback element renders in its place, and that fallback had its own click handler. Clicking it fired the fallback handler and then bubbled up to the wrapper handler, opening the destination twice. cx.stop_propagation() in the fallback resolves it. Images that 404 are common enough in READMEs that this path is worth exercising directly.

The whole feature is gated behind !self.style.prevent_mouse_interaction, so contexts that deliberately disable interaction are unchanged.

Testing

cargo test -p markdown, 95 tests passing, plus manual verification that badges open correctly and right click offers "Copy Link".

Merged as zed-industries/zed#59525.

The change

The panel already tracked per entry diff stats. It did not accumulate them into a single figure, which is what makes the size of a change readable at a glance. The work landed entirely in crates/git_ui/src/git_panel.rs: 50 lines added, 17 removed.

What the work involved

The arithmetic is trivial. Most of the time went into reading enough of the panel to find where its state lived and when it was recomputed, so the total stays in sync with the entries feeding it. In an unfamiliar Rust codebase, a small diff still means reading a lot of code to know where it goes.

I mentioned in the PR description that this was a first contribution and that I use Zed daily.

Merged as zed-industries/zed#58018.

Where the second prompt came from

create-vite hands off to the TanStack CLI to finish scaffolding. The Solid path passed --framework solid along with the handoff. The React path passed no framework argument, so the CLI prompted for one. Solid users never saw the prompt, React users always did.

Both paths scaffolded a correct project, so nothing errored and no test failed. The React branch had simply not been updated after a TanStack CLI behaviour change made the argument meaningful, and the only symptom was one extra prompt.

The fix

Pass --framework react, matching what the Solid branch already did. One line in packages/create-vite/src/index.ts.

Merged as vitejs/vite#22397.

What was leaking

The filter deciding what counted as a demo file matched two patterns: files under /routes/demo/, and files named /routes/demo.*.

Demo routes were excluded correctly. Everything supporting them was not:

• support files in /lib/, /hooks/, /data/, /components/, and /store/
• demo.index.css at the src/ root
• example assets in /public/, such as example-guitar-*.jpg and demo-neon.svg

All of it was copied into new projects with no routes referencing it.

Separately, the base scaffolding shipped a Header, a Footer, a ThemeToggle, a styled landing page, and an About route regardless of the answer.

The fix

isDemoRoutePath became isDemoFilePath, and the scope widened to match the new name. Support directories are covered, filtering extends to add-on integrations rather than routes and files alone, and the Better Auth header component became a template that renders null when its demo route is excluded, rather than linking to a route that no longer exists.

Two PRs became one

I had opened #431. Another contributor, @wyMinLwin, had opened #429 against the same problem. The maintainers combined both into a single unified fix, added coverage for edge cases neither PR had caught, and preserved both original commits with author credit.

Closes #422 and #409. Merged as TanStack/cli#434.

This PR added Drizzle ORM as a first-class add-on, with support for Postgres, MySQL, and SQLite.

Three drivers means most files become templates

A CLI add-on is not a library you import. It is a set of templates that has to produce correct, working code for every combination of choices a user can make, and supporting three drivers makes most of the interesting files driver specific.

Each driver needs its own:

• client construction: src/db/index.ts connects differently per driver
• schema syntax: Drizzle's column builders are driver specific, so a Postgres schema is not a MySQL schema
• config: drizzle.config.ts needs the right dialect and credentials shape
• environment variables: appended to .env.local, with a different connection string format per driver

Each of those became an EJS template branching on the selected driver, alongside an info.json describing the add-on to the CLI engine and a package.json.ejs pulling in the matching driver package, pg, mysql2, or a SQLite driver, rather than all three.

The demo route

The add-on also ships a working demo route. It exercises the client, the schema, and the config together, so a driver specific mistake in any of the three templates shows up when the demo route runs, before a user hits it. A later PR covered removing demo files like this one when a user opts out.

Where the work actually is

The hard part is the combinatorics rather than the feature. Every option multiplies the states the templates must produce valid output for, and the failure mode is quiet: a scaffold that looks fine and does not run. Templating one schema is easy. Templating three that are each idiomatic for their dialect is the work.

Merged as TanStack/cli#207.