Chained Server Fn Syntax, ServerFn Middleware

[tannerlinsley]

Todo:

• [x] Remove any "search" param specific terms/functionality from the validations utilities (including types and adapters)
• [ ] Publish new validation packages (without the router- prefix)
• [ ] Middleware Documentation

Nice To Have:

• [ ] registerServerMiddleware([a, b, c]) to add global middleware
• [ ] Companion declaration merging for the above to allow global middleware to also be type-safe
• [ ] Move all validation adapter packages into a new monorepo, e.g. TanStack Validate

Maybe?

• [ ] Middleware registry so middleware and server functions can simply reference middleware dependencies (type safe autocomplete too) by ID instead of importing them. However, this would essentially make any registered middleware global and un-treeshakable. TBH I'm not sure how tree shaking would work as is, if it does, and if it even makes a difference since it's on the server.

[ssijak]

Let's goooo 🚀

[nx-cloud[bot]]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit c4e66bb0e15ccd0bf3ab663aa1549067d2fc130f. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 2 targets

• nx affected --targets=test:eslint,test:unit,test:e2e,test:types,test:build,build --parallel=3
• nx run-many --target=build --exclude=examples/** --exclude=e2e/**

---

Sent with 💌 from NxCloud.

[ttsirkia]

This PR included a new Middleware Guide page for Start. It is visible as a link in Server Functions page but not in the main contents menu. Should it also be visible there?

[tannerlinsley]

Fixed.

[ttsirkia]

Great, thanks!

[thebuilder]

This PR silently changes the package name of adapters between two patch versions (1.18.5 and 1.18.6).

-import { zodSearchValidator } from '@tanstack/router-zod-adapter';
+import { zodValidator } from '@tanstack/zod-adapter';

After bumping dependencies, the types for searchParams becomes any, until the adapter package is changed to the new one.

Why isn't something like this marked as a breaking change, but just thrown into a huge PR with no description? Everyone using the adapters will run this issue once they start bumping dependencies, and have to do the same detective work to find out why it breaks.

The damage is done, but could you at least:

• Mark the old packages as deprecated, to give a hint to the developer that they should replace them
• Update the release note with a mention of the packages having changed name

[schiller-manuel]

@thebuilder sorry! this was absolutely not intended. in fact, we planned that the old packages could be continued to be used. But then we overlooked that the packages depended on a type exported from router :( I updated the release notes and we will deprecate the old packages asap.