Vite slows down navigation due to dependency optimization

[jansedlon]

Hi, I have recently migrated to Vite however the experience is not really that great. When I start my server it optimizes a bunch of dependencies which is fine. However when i navigate between pages, it optimizes more dependencies but it takes anywhere from 2s-10s. Sometimes it blocks the navigation completely and i have to click the link again, sometimes it redirects after a second but an error shows up for a second that something is not yet available (for example @conform-to/react tries to use useRef which fails for a second).

Is there a way to fix it? Like force to optimize all possible dependencies beforehand? Or is it a problem in vite with remix itself?

[jrestall]

Maybe Vite's warmup support can help. https://vitejs.dev/guide/performance#warm-up-frequently-used-files

If you think the remix plugin is to blame you can confirm by installing vite-plugin-inspect which will show the timings of each plugin. https://www.npmjs.com/package/vite-plugin-inspect

[jansedlon]

Thank you, however i didn't really find anything interesting :/ What @hi-ogawa said helped. Not sure if there are any consequences

[hi-ogawa]

Like force to optimize all possible dependencies beforehand? Or is it a problem in vite with remix itself?

Vite provides optimizeDeps.entries https://vitejs.dev/config/dep-optimization-options.html#optimizedeps-entries to achieve this, but as far as I know, it's not used by Remix. As explained in the doc, Vite automatically infers optimizeDeps.entries based on build.rollupOptions.input, but currently Remix doesn't set this either during dev, so Vite doesn't do any initial crawling.

Personally, I had a problem with e2e testing where some random window refresh during navigation makes tests too flaky, so I attempted to manually setup optimizeDeps.entries, which roughly looks like this:
(Note that my project haven't updated remix since 2.4.1, so things might have changed)

https://github.com/hi-ogawa/ytsub-v3/blob/f5074646e1ef45e671ea2f3fe28c236239173956/vite.config.ts#L71-L75
(EDIT: On this PR, I wrote more details about the idea hi-ogawa/ytsub-v3#536)

export default defineConfig({
  plugins: [
    // had to disable since false-positive error during optimizeDeps discovery?
    // https://github.com/remix-run/remix/pull/8267
    remix().filter((plugin) => plugin.name !== "remix-dot-server"),
  ],
  optimizeDeps: {
    // add this to crawl all routes
    entries: ["./app/entry-client.tsx", "./app/root.tsx", "./app/routes/**/*"],
  },
});

This worked in my case, but I have a little doubt that maybe some server only dependencies leak to client due to this.
(Note that optimizeDeps are dev only feature, so it shouldn't affect the build)

I haven't tested it but I think using server.warmup.clientFiles would be safer (though maybe slower or glitchy on initial request) since it goes through a same request pipeline.

It would be interesting if more people try server.warmup.clientFiles or optimizeDeps.entries so that we can provide feedback to Remix team.

[caprica]

This seemed to fix my issue as well.

The out-of-the-box developer experience with Remix and Vite was very disappointing until I made the changes you described here.

For me, I would see all manner of glitchy behaviour, initial page errors, weird non-navigation navigations where sometimes it would go to a new page, sometimes it would refresh the page it was on before the navigation. Sometimes it would just get stuck, Weird half-rendered or unstyled pages until a manual refresh and so on and so on.

But the suggestion given here seemed to resolve things for my project, so far it's working nicely.

[clayton-kenney]

So glad to find this thread. The migration to vite has been much bumpier than i had hoped, and the cold starts were taking 4+ minutes.

[khera]

I get this warning:

Cannot optimize dependency: ./app/entry.client.tsx, present in 'optimizeDeps.include'
Cannot optimize dependency: ./app/root.tsx, present in 'optimizeDeps.include'

So I have to remove those two from the list.

Also, I have some server and test files mixed in so I added

        "!**/*.server.(ts|tsx)",
        "!**/*.test.ts",

to both lists. This fixed the errors caprica was also observing with glitchy behavior.

[pcattori]

I think I've figured this out now. The solution is to (1) add your routes to optimizeDeps.entries as suggested by @hi-ogawa and then (2) patch packages/remix-dev/vite/plugin.ts:

 {
   name: "remix-dot-server",
   enforce: "pre",
   resolveId(id, importer, options) {
+     if (options?.scan) return // might need @ts-expect-error for this
     // ... rest of the plugin code ...
   }
 }

The issue was that the if (options?.ssr) return check was not being triggered during dependency optimization since the ssr field is omitted from the options during that pass. So to fix it, we can detect if the optimization pass is happening directly via options?.scan.

Going to verify that this is the fix and then we can ship this in Remix + React Router so it works out-of-the-box.
PR: #9921

[edbella]

I tried this but now I’m getting a ton of errors from
[plugin vite:dep-scan] - Server-only module referenced by client

E.g

import prisma from "~/prisma.server.ts"

export const loader = async () => {
    const result   await prisma.model.findUnique(...);

// Remaining code.
}

Not sure if this is because I’m using remix-flat-routes.

[pcattori]

The proposed solution should work for any/all routing conventions since it just reads the resolved routes from the Remix config. You're probably using an older version of the solution that relied on options?.ssr === false. Answer has been updated to rely on options?.scan instead as recommended by the Vite core team.

[edbella]

Yup yup. This works for me.

Although I should add that I patched your changes here into my working directory as well

[atticoos]

I just recently worked on similar optimizations on our application, and I found adding the routes to optimizeDeps.entries lead to Server-only module referenced by client errors -- and i'm wondering that behavior is unique to the remix() vite plugin, where perhaps its not hooking into this step of the build

Out of the box, Vite doesn't support mixing server-only code with client-safe code in the same module. Remix is able to make an exception for routes because we know which exports are server-only and can remove them from the client.

https://remix.run/docs/en/main/discussion/server-vs-client#splitting-up-client-and-server-code

This should be reproducible by adding a .server import on one of the routes

[ameyer117]

Hopefully this ends up getting fixed in React Router 7....

[jrestall]

Hopefully but likely more chance if an actual issue is raised rather than a discussion.

[fredericrous]

I experienced significative time improvements on page load, on the dev server, after I disabled compilerOptions.allowJS in tsconfig

[onozaty]

Remix 2.12.0 added future.unstable_optimizeDeps, does this flag change anything in how we deal with this issue?

[jansedlon]

I think it mostly, if not completely, solves the issue

[onozaty]

Thank you very much.

I am currently using the following settings, but will switch to this one when it changes to stable.

    warmup: {
      clientFiles: [
        "./app/entry.client.tsx",
        "./app/root.tsx",
        "./app/routes/**/*",
        "!./app/routes/**/*.test.{ts,tsx}",
      ],
    },