Vite error when importing from .server file. "Error: Server-only module referenced by client" #9035
Replies: 11 comments 33 replies
-
|
#8448 maybe you'll find something useful here |
Beta Was this translation helpful? Give feedback.
-
|
@joaoguidev That is odd. In my |
Beta Was this translation helpful? Give feedback.
-
|
Hello Kiliman. I noticed that different from your project, I'm using folders in my routes. I wonder if Vite and this style of structuring the routes might have something into it. Before migrating to Vite I had no such issue. So my routes look like this: Instead of this: Documentation here Another point worth mentioning is that I'm using the template for Cloudflare: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for providing more information. I'll see if I can reproduce the problem you're having. |
Beta Was this translation helpful? Give feedback.
-
This worked for me as well, thanks. However, it's definitely a step backwards because I have to manually type the import e.g. For what it's worth, I'm also using the folder-based routing, which is great by the way, so I would rather keep it as such. |
Beta Was this translation helpful? Give feedback.
-
|
I get the same error as you @joaoguidev and I also have a nested folder structure in /routes. That said, I don't think this is the issue since the epic stack follows this structure, and it too follows imports from |
Beta Was this translation helpful? Give feedback.
-
|
I am encountering a similar problem. Yet don't know if it's related. Even though the specified import is only used within the action function. Everything works great when using optimizeDeps: {
entries: [
'**/routes/**/*.{ts,tsx}',
],
},Anyone got an idea about this? |
Beta Was this translation helpful? Give feedback.
-
|
I'm having the same problem, event when the imported function is only used in the loader |
Beta Was this translation helpful? Give feedback.
-
|
Me too, whereas I seem to be able to use it in action exports just fine. |
Beta Was this translation helpful? Give feedback.
-
|
Specifying all routes like
like, its working for me 😇 Alternative: Use Vite's Auto-Detection
|
Beta Was this translation helpful? Give feedback.
-
|
Not sure what happened but I was going to try the solution @agathiyans28 suggested today and when I went to replicate the build error, I couldn't. Maybe Vite's Auto-Detection kicked in or maybe being on a different computer made it work differently but I no longer get this error. I tried adding |
Beta Was this translation helpful? Give feedback.
-
|
Vite's auto-detection can sometimes handle dependency optimization without manual intervention, so that might explain why adding optimizeDeps didn’t change the build output. It could also be related to differences in the environment between your computers. If everything is working fine now, that’s great. 😄 |
Beta Was this translation helpful? Give feedback.
-
|
For what it's worth: I had a similar problem:
but it turned out, I had imported a function from the I assume this is because remix determines if an import from a .server.js file is actually used in the loader function when deciding to throw this error or not. |
Beta Was this translation helpful? Give feedback.
-
|
@navdeep-soni I figured out the problem. I was using that in a component. This used to work in the classic remix compiler, however in the vite compiler it seems that .server.ts files can only be referenced from the routes. |
Beta Was this translation helpful? Give feedback.
-
|
I had the same problem, and this worked for me! |
Beta Was this translation helpful? Give feedback.
-
|
@isriram thank you, this resolved the issue for me! |
Beta Was this translation helpful? Give feedback.
-
|
This was my issue as well, have the import but commented out the method call temporarily, and the error showed up. Nice catch! |
Beta Was this translation helpful? Give feedback.
-
|
This solved it for me, thanks @arunaugustine. |
Beta Was this translation helpful? Give feedback.
-
|
OK now I'm having trouble integrating Trigger.dev because their initialization, which is based on file name routing rather than folder name routing, triggers this error. The automatically generated import { createRemixRoute } from "@trigger.dev/remix";
import { client } from "~/trigger.server";
// Remix will automatically strip files with side effects
// So you need to *export* your Job definitions like this:
export * from "~/jobs/example.server";
export const { action } = createRemixRoute(client);And when I try to build I get the error: Now, I don't think this should be an error and I think it's on the Remix side, but I'm not sure if anyone is working on this issue or if it's just not going to be fixed but I'd like to be able to integrate Remix with Trigger.dev so I'll try to see if they have any tips as well. |
Beta Was this translation helpful? Give feedback.
-
OK I've upgraded to Trigger.dev version 3 and this is no longer a problem. I thought I was initializing a version 3 application automatically since I was approved into the beta but I had to upgrade manually. When Trigger.dev is in version 3, it looks like there are no Remix-based web-hook URLs, so this shouldn't be a problem. |
Beta Was this translation helpful? Give feedback.
-
|
The code in your above post has a side effect, so the action code is not removed from client bundle. |
Beta Was this translation helpful? Give feedback.
-
|
it also happens when you re-export route relevant modules imported from other file. `+loader.tsx`
import { db, post } from '~/server/driver/db.server';
export const loader: LoaderFunction = async () => {
const result = await db.select().from(post).all();
return result;
};
...clientLoader, meta, etc`route.tsx`
...
export { loader, clientLoader, meta, shouldRevalidate } from './+loader';I splitted +loader.file into two, one that exports export { clientLoader, meta, shouldRevalidate } from './+meta';
export { action, headers, loader } from './+server';
export default Route; |
Beta Was this translation helpful? Give feedback.
-
|
This issue arises, when you have *.server files / folder used outside route modules, because remix does not remove *.server imports. It removes just imports from route modules which are only used within loader and action. If it happens to be a *.server import from the route module file, then everything is fine. But when the *.server import is hidden further down the import-chain, remix isn't going to remove it and so the server-only check will fail. Additionally, pure |
Beta Was this translation helpful? Give feedback.
-
|
The package The behavior makes sense: imagine you import a file Though I think there might be a thing that could be improved, because it seems to me its not the case currently: // bad: notice type is within {}
import {type Foo} from "./foo" // -> leaves import {} from "..."
// good: notice type outside {}
import type {Foo} from "./foo"it traverses the empty import and hits some potential In case its run before tree-shaking, maybe it can be changed to run after. The later would assume that when you don't import just as a side-effect |
Beta Was this translation helpful? Give feedback.
-
|
I was experiencing the a similar issue as the OP with regards to importing a type from a server-only file to non-server-only file. I wonder if there's something in the Vite or Remix/react-router docs than can provide further clarity why you need to make sure the ..either way. Thanks for providing the solution here! 🙏🏾 |
Beta Was this translation helpful? Give feedback.
-
|
Has nothing to do with remix or react-router. Types do not exist at runtime, so In order to depict explicitly, that you only want to load types (and not load the module, hence execute potential side-effects) is to use a pure type import // bar.ts
export type Bar = {}
console.log('bar side-effect')
// foo.ts
export type Foo = {}
console.log('foo side-effect')
// test.ts
import {type Bar} from "./bar"
import type {Foo} from "./foo"
function test(foo: Foo, bar: Bar) {}
console.log("end")Output: |
Beta Was this translation helpful? Give feedback.
-
|
@akomm that's true about type imports being a way to avoid any effect on run-time, but the issue in the OP affects real imports as well. |
Beta Was this translation helpful? Give feedback.
-
|
I was replying to a comment, not OP? |
Beta Was this translation helpful? Give feedback.
-
|
okay so if we're not supposed to use actions outside of routes, how do I do something like... have a signout button in a header that's present everywhere? It seems heavy-handed that Remix should dictate that my header must be part of my dashboard component and can't be a separate file... |
Beta Was this translation helpful? Give feedback.
-
|
Create a /signout page that performs the action. Redirect the user there when he clicks the btn. |
Beta Was this translation helpful? Give feedback.
-
|
You can also use a resource route for the signout with an action only to get the POST request: https://reactrouter.com/how-to/resource-routes |
Beta Was this translation helpful? Give feedback.
-
|
thanks for the thoughtful suggestions, both :) |
Beta Was this translation helpful? Give feedback.
-
|
We faced this issue during the migration from Remix v2 to RR7. We were using remix-flat-routes that are not configured correctly if you only follow the migration guide. Vite could pick up the routes correctly and strip away the server modules during the build and local "dev" process. Hope this helps! |
Beta Was this translation helpful? Give feedback.
-
🐛 Error: "Server-only module referenced by client" (Vite + Remix)✅ Solution found — scroll down for step-by-step fix We ran into the following Vite error when trying to use a 💡 ContextFile structure: In import { callAnAPI } from "../utils/example.server"; // ❌ Causes the errorThis breaks because client-side code can’t directly import server-only modules. ✅ Solution: Use an API route to bridge client ↔ serverWe resolved it by moving the server logic into a server-side action route and calling it from the hook using 🔧 Step-by-Step Fix1. Create a server-side action route
import type { ActionFunction } from "@remix-run/node";
import { json } from "@remix-run/node";
export const action: ActionFunction = async ({ request, context }) => {
const { callAnAPI } = await import("../utils/example.server");
const { session } = context;
const shop = session?.shop;
const formData = await request.formData();
const chunk = JSON.parse(formData.get("chunk") as string);
try {
const response = await callAnAPI(shop, chunk);
if (response.ok) {
return json({ success: true, failedProducts: [] });
}
return json({ success: false, failedProducts: chunk });
} catch (error: any) {
console.error("Server error:", error);
return json({ success: false, failedProducts: chunk, error: error.message }, { status: 500 });
}
};2. Call the server route from the hook
import { useFetcher } from "@remix-run/react";
export function useSendProducts() {
const fetcher = useFetcher();
const sendProducts = async (chunk: Product[]): Promise<{ success: boolean; failedProducts: Product[] }> => {
try {
const formData = new FormData();
formData.append("chunk", JSON.stringify(chunk));
fetcher.submit(formData, {
method: "POST",
action: "/api/send-products",
});
return new Promise((resolve) => {
const checkFetcher = setInterval(() => {
if (fetcher.state === "idle" && fetcher.data) {
clearInterval(checkFetcher);
const { success, failedProducts, error } = fetcher.data;
if (error) console.error("Fetcher error:", error);
resolve({ success, failedProducts: failedProducts || chunk });
}
}, 100);
});
} catch (error) {
console.error("Error sending products:", error);
return { success: false, failedProducts: chunk };
}
};
return { sendProducts };
}3. Use server-only logic in the loader (safe)
import { json } from "@remix-run/node";
import type { LoaderFunctionArgs } from "@remix-run/node";
export async function loader({ request }: LoaderFunctionArgs) {
const { getProducts } = await import("../utils/example.server");
const { session } = await authenticate.admin(request);
const shop = session.shop;
const result = await getProducts(shop);
return json({ result });
}In your component: export default function ExamplePage() {
const { result } = useLoaderData<typeof loader>();
return <pre>{JSON.stringify(result, null, 2)}</pre>;
}✅ Outcome
|
Beta Was this translation helpful? Give feedback.
-
|
Hi @kiliman, I’ve shared a detailed answer in the discussion #9035 that I believe could help others facing the same issue. Would it be possible to pin or mark my comment as the answer to make it more visible to the community? I’d appreciate your consideration! Thanks, Mahdi Hamldar |
Beta Was this translation helpful? Give feedback.
-
|
The answer feels totally detached from current conversation state. It does not answer why error happens (has been answered above many times). It shoots with a canon using weird Your example even needlessly uses async import, because at this position a regular import would have been pruned by remix and the error would not haven appeared either. The issue was the usage of the .server file in client code outside action/loader. |
Beta Was this translation helpful? Give feedback.
-
|
All of these solutions seem backwards. The entire point of Remix is to write full-stack applications. Loaders, actions, and the rendered component/page are all in the same file. Loaders and actions should be able to import .server files Observations:
|
Beta Was this translation helpful? Give feedback.
-
|
Loader and action function are able to import .server files. Remix will remove this imports if used only in loader or action. Any time I had this apparent situation myself, it turned out some non-server file, within which a .server import is hidden somewhere deep triggered it. Maybe even to the same file you import and use only in action and loader. So you see the file you apparently only use in loader and action, but the error on that file was not triggered via the route module import, but via some other import that also end up pulling the same .server file. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello.
I have a file named validation.server.jsx that I use to export a schema validation function.
As the name indicates, it is a .server file with code to run exclusively server-side.
I then use the exported function from the referred file to validate data inside the action of my route.jsx.
Now with Vite, Im getting the error below just by importing the function from the validation.server.jsx file into my app/routes/admin/route.jsx.
import { validateSchema } from "../../lib/validation.server"By making this import I get the error or any import from a .server file into a route.jsx file i get the error:
It seems that it was dealt with before but im still getting this problem: #8267
Beta Was this translation helpful? Give feedback.
All reactions