Merge branch 'main' into plugins-again

Author: LadyBluenotes

AGENTS.md

@@ -246,3 +246,40 @@ For runtime testing and verification, developers should:
 ### Summary Rule
 
 **If depth does not improve comprehension, remove it.**
+
+## Writing Style
+
+### Avoid Emdashes
+
+**Never use emdashes (—) in writing. They make content smell like AI-generated text.**
+
+Use these alternatives instead:
+
+- Commas for parenthetical phrases
+- Colons to introduce lists or explanations
+- Periods to break into separate sentences
+- Parentheses when appropriate
+
+❌ **Bad:**
+
+```
+RSCs aren't about replacing client interactivity — they're about choosing where work happens.
+```
+
+✅ **Good:**
+
+```
+RSCs aren't about replacing client interactivity. They're about choosing where work happens.
+```
+
+❌ **Bad:**
+
+```
+Heavy dependencies — markdown parsers, syntax highlighters — stay on the server.
+```
+
+✅ **Good:**
+
+```
+Heavy dependencies (markdown parsers, syntax highlighters) stay on the server.
+```

media/brand.sketch

@@ -37,7 +37,7 @@ That page will stay current with the exact commands for the RC and the final 1.0
 
 ## Path to 1.0 stable
 
-We plan to cut 1.0 shortly after collecting RC feedback. Expect a few small RC iterations; any breaking changes will be clearly documented. As we approach stable, only light polish remains—no major API shifts.
+We plan to cut 1.0 shortly after collecting RC feedback. Expect a few small RC iterations; any breaking changes will be clearly documented. As we approach stable, only light polish remains. No major API shifts.
 
 > **Note:** React Server Components support is in active development and will land as a non-breaking v1.x addition.
 
@@ -67,6 +67,6 @@ Their collaboration is a pivotal force driving the open web forward. Explore the
 
 ## Your feedback counts
 
-This is the moment when your feedback matters most. Try the RC in a new or existing project and tell us what you think via the docs feedback links. If you hit an issue, the migration notes and examples in the docs will help—and we’ll be quick to respond.
+This is the moment when your feedback matters most. Try the RC in a new or existing project and tell us what you think via the docs feedback links. If you hit an issue, the migration notes and examples in the docs will help. And we’ll be quick to respond.
 
 Thanks for building with us. Let’s ship 1.0, together.

public/blog-assets/composite-components/header.jpg

@@ -18,7 +18,7 @@ Netlify has earned its reputation as the ultimate deployment platform for modern
 
 ## Why Netlify?
 
-Netlify is more than just a deployment provider—they’ve worked closely with us to ensure that deploying TanStack Start applications is not just fast, but optimized for the best possible developer experience. Whether you’re building interactive UIs, data-heavy dashboards, real-time tools, or AI-powered applications, Netlify’s platform makes the process seamless.
+Netlify is more than just a deployment provider. They’ve worked closely with us to ensure that deploying TanStack Start applications is not just fast, but optimized for the best possible developer experience. Whether you’re building interactive UIs, data-heavy dashboards, real-time tools, or AI-powered applications, Netlify’s platform makes the process seamless.
 
 As part of this partnership, Netlify has also launched a **full-stack AI chatbot starter template** that showcases TanStack Start’s powerful data management capabilities alongside Netlify Functions. This template provides:
 

public/blog-assets/tanstack-start-rsc/header.jpg

@@ -7,9 +7,9 @@ authors:
 
 ![Search Params Are State Header](/blog-assets/search-params-are-state/search-params-are-state-header.jpg)
 
-## Search Params Are State — Treat Them That Way
+## Search Params Are State . Treat Them That Way
 
-Search params have been historically treated like second-class state. They're global, serializable, and shareable — but in most apps, they’re still hacked together with string parsing, loose conventions, and brittle utils.
+Search params have been historically treated like second-class state. They're global, serializable, and shareable . but in most apps, they’re still hacked together with string parsing, loose conventions, and brittle utils.
 
 Even something simple, like validating a `sort` param, quickly turns verbose:
 
@@ -30,7 +30,7 @@ This works, but it’s manual and repetitive. There’s no inference, no connect
 
 Even worse, `URLSearchParams` is string-only. It doesn’t support nested JSON, arrays (beyond naive comma-splitting), or type coercion. So unless your state is flat and simple, you’re going to hit walls fast.
 
-That’s why we’re starting to see a rise in tools and proposals — things like Nuqs, Next.js RFCs, and userland patterns — aimed at making search params more type-safe and ergonomic. Most of these focus on improving _reading_ from the URL.
+That’s why we’re starting to see a rise in tools and proposals . things like Nuqs, Next.js RFCs, and userland patterns . aimed at making search params more type-safe and ergonomic. Most of these focus on improving _reading_ from the URL.
 
 But almost none of them solve the deeper, harder problem: **writing** search params, safely and atomically, with full awareness of routing context.
 
@@ -56,15 +56,15 @@ Constraint is what makes coordination possible. It’s what allows **non-local c
 
 ---
 
-### Local Abstractions Can Help — But They Don’t Coordinate
+### Local Abstractions Can Help . But They Don’t Coordinate
 
-Tools like **Nuqs** are a great example of how local abstractions can improve the _ergonomics_ of search param handling. You get Zod-powered parsing, type inference, even writable APIs — all scoped to a specific component or hook.
+Tools like **Nuqs** are a great example of how local abstractions can improve the _ergonomics_ of search param handling. You get Zod-powered parsing, type inference, even writable APIs . all scoped to a specific component or hook.
 
-They make it easier to read and write search params **in isolation** — and that’s valuable.
+They make it easier to read and write search params **in isolation** . and that’s valuable.
 
 But they don’t solve the broader issue of **coordination**. You still end up with duplicated schemas, disjointed expectations, and no way to enforce consistency between routes or components. Defaults can conflict. Types can drift. And when routes evolve, nothing guarantees all the callers update with them.
 
-That’s the real fragmentation problem — and fixing it requires bringing search param schemas into the routing layer itself.
+That’s the real fragmentation problem . and fixing it requires bringing search param schemas into the routing layer itself.
 
 ---
 
@@ -100,13 +100,13 @@ navigate({
 })
 ```
 
-It’s reducer-style, transactional, and integrates directly with the router’s reactivity model. Components only re-render when the specific search param they use changes — not every time the URL mutates.
+It’s reducer-style, transactional, and integrates directly with the router’s reactivity model. Components only re-render when the specific search param they use changes . not every time the URL mutates.
 
 ---
 
 ### How TanStack Router Prevents Schema Fragmentation
 
-When your search param logic lives in userland — scattered across hooks, utils, and helpers — it’s only a matter of time before you end up with **conflicting schemas**.
+When your search param logic lives in userland . scattered across hooks, utils, and helpers . it’s only a matter of time before you end up with **conflicting schemas**.
 
 Maybe one component expects \`sort: 'asc' | 'desc'\`. Another adds a \`filter\`. A third assumes \`sort: 'desc'\` by default. None of them share a source of truth.
 
@@ -117,7 +117,7 @@ This leads to:
 - Navigation that sets values others can’t parse
 - Broken deep linking and bugs you can’t trace
 
-TanStack Router prevents this by tying schemas directly to your route definitions — **hierarchically**.
+TanStack Router prevents this by tying schemas directly to your route definitions . **hierarchically**.
 
 Parent routes can define shared search param validation. Child routes inherit that context, add to it, or extend it in type-safe ways. This makes it _impossible_ to accidentally create overlapping, incompatible schemas in different parts of your app.
 
@@ -160,23 +160,23 @@ validateSearch: z.object({
 })
 ```
 
-This kind of enforcement makes nested routes composable _and_ safe — a rare combo.
+This kind of enforcement makes nested routes composable _and_ safe . a rare combo.
 
 ---
 
 ### Built-In Discipline
 
 The magic here is that you don’t need to teach your team to follow conventions. The route _owns_ the schema. Everyone just uses it. There’s no duplication. No drift. No silent bugs. No guessing.
 
-When you bring validation, typing, and ownership into the router itself, you stop treating URLs like strings and start treating them like real state — because that’s what they are.
+When you bring validation, typing, and ownership into the router itself, you stop treating URLs like strings and start treating them like real state . because that’s what they are.
 
 ---
 
 ### Search Params Are State
 
 Most routing systems treat search params like an afterthought. Something you _can_ read, maybe parse, maybe stringify, but rarely something you can actually **trust**.
 
-TanStack Router flips that on its head. It makes search params a core part of the routing contract — validated, inferable, writable, and reactive.
+TanStack Router flips that on its head. It makes search params a core part of the routing contract . validated, inferable, writable, and reactive.
 
 Because if you’re not treating search params like state, you’re going to keep leaking it, breaking it, and working around it.
 

src/blog/announcing-tanstack-start-v1.md

@@ -15,7 +15,7 @@ Our goals were simple: move away from monolithic adapters and their complexity,
 
 ## New Adapter Architecture
 
-We wanted to support everything AI providers offer—image generation, video, audio, text-to-speech, transcription—without updating every adapter simultaneously.
+We wanted to support everything AI providers offer. Image generation, video, audio, text-to-speech, transcription. Without updating every adapter simultaneously.
 
 We're a small team. Adding image support shouldn't mean extending `BaseAdapter`, updating 5+ provider implementations, ensuring per-model type safety for each, and combing through docs manually. That's a week per provider. Multiply that by 20 providers and 6 modalities.
 
@@ -37,7 +37,7 @@ import { openaiText, openaiImage, openaiVideo } from '@tanstack/ai-openai'
 
 **Incremental feature support.** Add image generation to OpenAI this week, Gemini next week, video for a third provider the week after. Smaller releases, same pace.
 
-**Easier maintenance.** Our adapter abstraction had grown to 7 type generics with only text, summarization, and embeddings. Adding 6 more modalities would have exploded complexity. Now each adapter is focused—3 generics max.
+**Easier maintenance.** Our adapter abstraction had grown to 7 type generics with only text, summarization, and embeddings. Adding 6 more modalities would have exploded complexity. Now each adapter is focused. 3 generics max.
 
 **Better bundle size.** You control what you pull in. Want only text? Import `openaiText`. Want text and images? Import both. Your bundle, your choice.
 
@@ -168,4 +168,4 @@ We're confident in this direction. We think you'll like it too.
 
 <!-- ---
 
-_Curious how we got here? Read [The `ai()` Function That Almost Was](/blog/tanstack-ai-the-ai-function-postmortem)—a post-mortem on the API we loved, built, and had to kill._ -->
+_Curious how we got here? Read [The `ai()` Function That Almost Was](/blog/tanstack-ai-the-ai-function-postmortem). a post-mortem on the API we loved, built, and had to kill._ -->

src/blog/tanstack-start-rsc.md src/blog/composite-components.mdsrc/blog/tanstack-start-rsc.md renamed to src/blog/composite-components.md

@@ -36,7 +36,7 @@ ai({
 })
 ```
 
-Simple. Single function. Powers everything AI-related. Clear naming—you're using AI. Types constrained to each adapter's capabilities. Pass image options to an image adapter, text options to a text adapter.
+Simple. Single function. Powers everything AI-related. Clear naming. You're using AI. Types constrained to each adapter's capabilities. Pass image options to an image adapter, text options to a text adapter.
 
 Change models? Type errors if something's not supported. Change adapters? Type errors if something's not supported.
 
@@ -54,7 +54,7 @@ The simplicity of `ai()` for end users hid enormous implementation complexity.
 
 **Attempt 1: Function Overloads**
 
-We tried using function overloads to constrain each adapter's options. Too many scenarios. The overloads resolved to wrong signatures—you could end up providing video options instead of image options. We got it to 99% working, but the 1% felt wrong and was a bigger hurdle than you'd think.
+We tried using function overloads to constrain each adapter's options. Too many scenarios. The overloads resolved to wrong signatures. You could end up providing video options instead of image options. We got it to 99% working, but the 1% felt wrong and was a bigger hurdle than you'd think.
 
 Having 10+ overloads is cumbersome. Get the order wrong and it all falls apart. This would exponentially increase the difficulty of contributions and lowered our confidence in shipping stable releases.
 
@@ -68,7 +68,7 @@ We'll take complexity on our side over forcing you to use `as` casts or `any` ty
 
 ### The aiOptions Nightmare
 
-We added a `createXXXOptions` API—`createTextOptions`, `createImageOptions`, etc. You can construct options as ready-made agents and pass them into functions, overriding what you need.
+We added a `createXXXOptions` API. `createTextOptions`, `createImageOptions`, etc. You can construct options as ready-made agents and pass them into functions, overriding what you need.
 
 To match the theme, we called it `aiOptions`. It would constrain everything to the modality and provider:
 
@@ -82,13 +82,13 @@ ai(opts)
 
 Here's where we hit the wall.
 
-When `aiOptions` returned readonly values, spreading into `ai()` worked. But `aiOptions` was loosely typed—you could pass anything in.
+When `aiOptions` returned readonly values, spreading into `ai()` worked. But `aiOptions` was loosely typed. You could pass anything in.
 
 When we fixed `aiOptions` to accept only valid properties, the spread would cast the `ai()` function to `any`. Then it would accept anything.
 
 We went in circles. Get one part working, break another. Fix that, break the first thing.
 
-I believe it could have been done. Our approach was probably just wrong—some subtle bug in the system causing everything to break. But that proves the point: it was too complex to wrap your head around and find the root cause. Any fix would have to propagate through all the adapters. Very costly.
+I believe it could have been done. Our approach was probably just wrong. Some subtle bug in the system causing everything to break. But that proves the point: it was too complex to wrap your head around and find the root cause. Any fix would have to propagate through all the adapters. Very costly.
 
 We spent almost a week trying to get this API to work perfectly. We couldn't. Maybe another week would have done it. But then what? How would we fix bugs in this brittle type system? How would we find root causes?
 
@@ -98,7 +98,7 @@ Even if we'd gotten it working, there was another problem.
 
 We'd just split our adapters into smaller pieces so bundlers could tree-shake what you don't use. Then we put all that complexity right back into `ai()`.
 
-We don't want to be the lodash of AI libraries—bundling everything you don't use and calling it a day. If a huge adapter that bundles everything is not okay, a single function that does the same thing is definitely not okay.
+We don't want to be the lodash of AI libraries, bundling everything you don't use and calling it a day. If a huge adapter that bundles everything is not okay, a single function that does the same thing is definitely not okay.
 
 ## The Warnings We Missed
 
@@ -112,7 +112,7 @@ The warning sign we missed? LLMs couldn't reliably generate code for this API.
 
 Think about that. We're building tools for AI, and AI couldn't figure out how to use them. That should have been a massive clue that humans wouldn't reliably write to this API unaided either.
 
-LLMs like function names that indicate what the thing does. `ai()`—who knows? `generateImage()`—crystal clear.
+LLMs like function names that indicate what the thing does. `ai()`? Who knows. `generateImage()`? Crystal clear.
 
 When we finally asked the LLMs directly what they thought of the API, they were 4-0 against `ai()` and for the more descriptive approach we ended up with.
 
@@ -147,7 +147,7 @@ adapter.image('model')
 adapter.text('model')
 ```
 
-Looks nicer. Feels more unified. Same problem—still bundles everything.
+Looks nicer. Feels more unified. Same problem: still bundles everything.
 
 We could have done custom bundling in TanStack Start to strip unused parts, but we don't want to force you to use our framework for the best experience. This library is for the web ecosystem, not just TanStack users.