CreateServerFns Code Being bundled exposed and called in the client 1.136.8 #5892

Activity

1. schiller-manuel

   added

   information neededFurther information is requestedFurther information is requested

   on Nov 18, 2025
2. schiller-manuel commented on Nov 18, 2025

   

   schiller-manuel

   on Nov 18, 2025

   Collaborator

   More actions

   please provide a complete example project that reproduces this
3. mike-littlechapter commented on Nov 18, 2025

   

   mike-littlechapter

   on Nov 18, 2025

   Author

   More actions

   @schiller-manuel Please see this minimal reproduction

   https://github.com/mike-littlechapter/client-bundle-reproduction

   I traced it down to creating server functions and providing Type Arguments

   providing a type argument to a server fn in v1.132.2+ will lead to it being bundled into the client

   This was previously not the case in versions lower than v1.132.2, and so im sure many people are being caught by this during the upgrade process as theres no information about this in the docs or migration guide, and no errors or warnings are thrown when a serverfn fails to be bundled correctly for whatever reason.

   For me i had a lot of type arguments on the handler() call as it was easier than setting the return type on the actual handler fn and meant i didnt need to wrap all my return types in Promise (pre v1.132.2).

   There was nothing in the docs that said i couldnt do this, and tanstack-start correctly accepted the type argument and produced the right return types. In fact it still infers the same return type whether you type the handler type argument or the return type of the actual enclosed handler fn in v1.132.2+.

   const serverFunctionSchema = z.object({
     foo: z.string(),
   });
   
   const getRequestSrver = createServerOnlyFn(() => {
     return getRequest();
   });
   
   export const TypeServerFN = createServerFn({
     method: 'POST',
   })
     .inputValidator(serverFunctionSchema)
     .handler<Promise<{ origin: string | null }>>(async ({ data }) => {
       const { foo } = data;
       const req = getRequestSrver();
       const origin = req.headers.get('origin');
       console.log('logging here to search in output TYPE');
       console.log(' SUPER SECRET SERVER STUFF: password is 12345');
       return { origin: origin };
     });

   I suggest that something be added to the migration guide ASAP
4. schiller-manuel commented on Nov 19, 2025

   

   schiller-manuel

   on Nov 19, 2025

   Last edited by schiller-manuel

   Collaborator

   More actions

   you should not specify any types as all types are inferred.

   this has always been the case.
5. schiller-manuel

   closed this as completedon Nov 19, 2025
6. mike-littlechapter commented on Nov 19, 2025

   

   mike-littlechapter

   on Nov 19, 2025

   Last edited by mike-littlechapter

   Author

   More actions

   @schiller-manuel
   @tannerlinsley

   This is not clear at all, and I like many others prefer writing return types to ensure the functions conform to a correct contract. the inferred types can be difficult to read and use in development especially when there are unions in the return types.

   In any case. i do think this is an issue and needs to have better documentation on this as well as error logs when user defined server functions are not bundled correctly due to user error.

   The fact that this minor and regular typescript development practice can lead to a complete failure of tanstack start without any warning or errors is in my opinion a critical issue.

   Can you please point me to where the information about providing return types on serverFns being invalid and leading to server code being bundled into the client is located?

   I cant quite seem to find the documentation link, could you please provide a link to the docs on this topic here at least for other users landing on this issue?

   there doesn't seem to be anything in https://tanstack.com/start/latest/docs/framework/react/guide/server-functions
7. schiller-manuel commented on Nov 19, 2025

   

   schiller-manuel

   on Nov 19, 2025

   Collaborator

   More actions

   the documentation does not contain any trace of manual typing for createServerFn.
   i would use a satisfies inside of the handler instead. does that work for you?

   better warning / errors are definitely something we can look into here.
8. mike-littlechapter commented on Nov 19, 2025

   

   mike-littlechapter

   on Nov 19, 2025

   Last edited by mike-littlechapter

   Author

   More actions

   @schiller-manuel i personally dont think that level of docs is sufficient.

   Documentation for many projects often doesnt make use of strict typing or additional type arguments, and it is typically not thought to mean that you absolutely CANT do that, and is assumed that return types etc are just omitted to make the code more concise for examples and documentation purposes.

   If providing a return type in a typescript focused project leads to an entire breakdown of the projects core promises then I personally think it should be explicitly stated that you absolutely must NOT do that.

   By your definition of the docs not showing this done therefore its not possible, should i assume that serverFns cannot create new Set()'s within the function body? I don't think theres any examples of that within the docs, and i certainly shouldn't expect that the omission of that example means that doing so will lead to the serverFn being bundled into the client....

   At least having this highlighted in the migration guide would be good as this appears to only be an issue from v1.132 onwards.

   Or perhaps it should be in https://tanstack.com/start/latest/docs/framework/react/guide/code-execution-patterns

   Im not fussed dealing with having no return types. its just that its such an easy an ostensibly innocuous thing to do however the impact is that your entire project breaks.

   For new projects you might pickup on what you just did and be able to revert it. But for projects migrating to v1.132, if they have these return types throughout the codebase, your entire project is basically un-debuggable without starting from scratch.
   and is in state where all your server functions are suddenly in the client bundle and your project is dead. The fact that theres no information about this in the docs or online is pretty bad.

   My only consolation is hopefully this issue can be indexed into google and discoverable by users running into the same issue and pulling their hair out

   This would be easily solved with some documentation.

   And progressively improved with warnings in the bundling process. im sure calling createServerFn makes the fn visible to tanstack, and it should be very easy to detect if you have createServerFn's within the client for some reason and provide a hint that "maybe you provided return types, DON'T DO THAT"

   👍React with 👍10Reacted by Arnaud Benhamdine, shinexoh, Sebastian Pietschner, Abdulmalik Yusuf, slevy85, Nils Bunger, humemm, Adam Weber, micchat and Walnuts