🗺️ Just use vite!

[ryanflorence]

"Just Use Vite!"

Background

Over-reliance on compilers is often to blame for apps being slow and clunky for both the developer and users, so our initial approach with Remix was to keep it simple and limited. By keeping the compiler closed we were able to ensure builds remained fast and bundles remained small.

Unfortunately this is one of the biggest hurdles for adopting Remix. We've slowly been adding features to the Remix compiler to try to help, but it barely makes a scratch.

Preventing teams from making their own tradeoffs around compilers was never our intent and innovating in the compiler space has never really been a goal of ours.

Proposal

Because innovating in the compiler space is not a goal of Remix, we've decided to use a tool created by a community of folks who have been doing a great job at this: Vite.

Why didn't you use Vite originally?

Vite didn't exist when we started Remix, and until recently, didn't have the capabilities needed to power the development workflow of a full-stack, cross-runtime-environment framework like Remix.

For example, Vite's built-in HMR won't work as you expect if you change the data returned from a loader and change a component that uses that data at the same time. This is because HMR was originally designed for SPA and doesn't know anything about fetching fresh data from the app server. This is why Remix first developed HDR internally before adopting Vite.

Usage

Future Flag

Because the compiler is the entry point of Remix, there is no future flag in remix.config for the Vite compiler.

vite.config.ts and plugin

Use the unstable_remix plugin to configure Vite for Remix:

import { defineConfig } from "vite";
import { unstable_remix } from "@remix-run/vite";

export default defineConfig({
  plugins: [
    // remix.config.js moves to `remixConfig` here
    unstable_remix(remixConfig),
  ],
});

When using Vite, the Remix config moves from remix.config.js to the argument passed to the Remix Vite plugin. Copy/paste it in there and delete the remix.config.js file.

Some options no longer apply like port. Vite has its own config for these and we'll make sure to document them all.

Remix CLI

{
  "scripts": {
- "build": "remix build",
- "dev": "remix dev"
+ "build": "vite build && vite build --ssr",
+ "dev": "vite dev"
  }
}

Vite Plugins

The old Remix compiler supports several file types like asset imports, CSS module, MDX, etc. The Remix Vite plugin does not support those directly, but Vite does and that's the point!

TypeScript

import { defineConfig } from "vite";
import { unstable_remix } from "@remix-run/vite";
import tsconfigPaths from "vite-tsconfig-paths";

export default defineConfig([
  tsconfigPaths(),
  unstable_remix(remixConfig),
]);

MDX

import { unstable_remix } from "@remix-run/vite";
import { legacy_css } from "@remix-run/legacy-vite";
import { mdx } from "vite-plugin-mdx";
import remarkFrontMatter from "remark-frontmatter";
import remarkMdxFrontMatter from "remark-mdx-frontmatter";

export default defineConfig({
  server: { port: 3000 },
  plugins: [
    unstable_remix({
      legacy_css: true
    }),
    tsconfigPaths(),
    mdx({
      remarkPlugins: [
        remarkFrontMatter,
        remarkMdxFrontMatter,
      ],
    }),
  ],
});

Server Setup

Remix App Server

If you're using the Remix App Server, you just run vite dev, it will do the rest.

$ vite dev

Express Server

With an express server, you integrate Vite directly into your node server. That means you run your app with the same command in dev and prod:

$ node ./server.js # prod
$ NODE_ENV=development node ./server.js # dev

This also avoids needing to run two processes and enables the development tooling like HMR.

import express from "express";
import { createRequestHandler } from "@remix-run/node";

const app = express();

app.use(
  process.env.NODE_ENV === "production"
    ? express.static("public")
    // in dev use vite for static assets
    : await import("@remix-run/vite").devMiddleware()
);

app.all(
  "*",
  createRequestHandler({
    getLoadContext() {},
    build:
      process.env.NODE_ENV === "production"
        ? import("./build"),
        // in dev use vite's server build
        : import("@remix-run/vite").build(),
  })
);

Keep @remix-run/vite in devDependencies and use dynamic imports to avoid installing the these dependencies in production.

Your vite config will need to specify the adapter as well:

import { defineConfig } from "vite";
import { unstable_remix, node } from "@remix-run/vite";
import tsconfigPaths from "vite-tsconfig-paths";

export default defineConfig([
  tsconfigPaths(),
  unstable_remix({
    adapter: node(),
  }),
]);

Cloudflare

I don't know yet, but Fran will.

//

Benefits

This puts app developers in charge of their compilation tradeoffs instead of Remix prescribing. Folks can use Vite's plugins to add support for whatever they need like importing .graphql files, svg icons, etc.

Most importantly, this removes a huge adoption barrier for React Router apps to upgrade to Remix.

[pavankjadda]

This is great news. Definitely makes our job easier to play with Remix (who knows, may be adopting)

[sergiodxa]

I love this

import { defineConfig } from "vite";
import { unstable_remix } from "@remix-run/vite";

export default defineConfig({
  plugins: [
    // remix.config.js moves to `remixConfig` here
    unstable_remix(remixConfig),
  ],
});

A world where the framework is just a plugin of the compiler. This should also help migrate from React Router to Remix, if the RR app uses Vite it can just add the Remix plugin once the code is structured to work the same way.

[kensnyder]

Love it. As I understand both Remix and Vite use esbuild under the hood. It sounds like Remix changing to Vite is less about performance and more about controlling the build, integrating Vite plugins, and improved HMR. Is that right?

[kensnyder]

Hey Ryan!

Great to hear! When I fix bugs, I often fire up a GitHub Codespace. Even with their fastest server option, rebuilding takes 5 to 10 seconds. Local rebuilds are much more managable.

Our Remix app is up to 90 routes now, so we are keen on anything that can speed up builds and rebuilds.

[ryanflorence]

Rebuilds that take that long today seems sus.

[markdalgleish]

@kensnyder We were actually looking into performance issues with esbuild when compiling apps that depend on massive component libraries. We started exploring pre-bundling of dependencies to work around this, but this ended up being the tipping point where we decided we should probably just use Vite.

[yarapolana]

Been experiencing build times up to 21 sec (not so many routes 10+) so I'll definitely try the vite approach.

[kensnyder]

@markdalgleish Love it. Yes, we use some big libraries that need significant treeshaking including MUI, MUI icons, Font Awesome icons, various @azure/* libs, lodash-es, usehooks-ts, and rooks.

[ngbrown]

For the Express server.js setup, I would love to see a TypeScript server.ts be the default entry point during dev with a built server.js for deployment.

[cliffordfajardo]

Same, unless there is some vite plugin or typescript config setting that would allow us to import a .ts file inside of server.js 🤔

Reason I bring this up is because production remix-express apps often have lots of extra custom code:

• ex: middleware for application perf monitoring (APM)
• ex: setup graphql (ex: apollo) via middleware
• ex: logging middleware (prometheus metrics -> grafanaa)

I had a massive server.js file and ended up splititng it out and making my entry point server.ts since coding with that the types was very error prone 😓

server.ts

[pcattori]

Since the extensible server option (e.g. using Express directly) ends up being a server.mjs file that you run yourself (e.g. via node ./server.mjs), you can rename to server.ts and use whatever mechanism you prefer for running that file: ts-node, tsx, node --loader tsm, or anything you prefer.

[celebro]

The problem with using own build mechanism for outer server is that modules can't be shared between server and app. Or code itself can be, but modules will have separate instances. So anytime there are module scoped variables, server will use its own copy of those variables (bundled by us) and app will use its own (build by vite).

Remix compiler enabled an interesting pattern. I use server: './app/server.ts' in remix.config.js, app/server.ts creates the entire express server but does not start it, instead it exports it, e.g.

import * as build from '@remix-run/dev/server-build'

const app = express();
app.use('/build', express.static(...)
app.all('*', createRequestHandler({ build, ...}))

export { app, build }

And the outer ./server.js imports the app and build then starts listening, and in dev also handles reimporting on build change, e.g.

let serverbuild = await import(BUILD_PATH);
if (NODE_ENV === 'development') {
  app = function(req, res) {
    return serverbuild.app(req, res)
    startListeningForBuildChangesAndReimportServerBuild();
}
http.createServer(app).listen(PORT);

Using this, entire server-side code is part of one bundle, I don't need any separate build or custom run command, modules can easily be shared between express server parts and remix app, and I also get hot reload of my app/server.ts for free.

It would be really great is a similar patter could be achieved using vite.

[afoures]

Awesome 🔥 will HDR work with Vite? just saw it in #7590

[YannBirba]

I'm just so hype

[DreierF]

Have you thought about adding the possibility to just compile a Remix structured app to a SPA React Router app? This would make it even easier to gradually adopt Remix and would also allow people who cannot run a Node backend to benefit from using the Remix way of defining routes. Could this be done with a custom adapter implementation?

[sergiodxa]

This #7638 ?

[DreierF]

💯 Exactly! Thanks for the pointer!

[richardscarrott]

Kinda makes me nervous we’ll be maintaining bundler config across all our sites like the days before meta frameworks. I dread to think the amount of time I’ve spent configuring webpack and upgrading out of date plugins etc.

Having said that, Vite config looks much simpler and I guess all we’d really need is the remix plugin + static assets 🤔

[pablomayobre]

I imagine there will be templates like the ones for React and other tools.

If you have been using create-react-app, create-next-app or similar they all are templates that bundle their own we pack/rollup/vite or other bundlers configurations.

So I would expect that the Remix stacks we all know and love will come with sane vite configs by default that you can extend later

[ryanflorence]

You won't need anything more than the remix plugin. So if you get into bundler config hell, you did it to yourself! 😅

[aaronadamsCA]

Assuming this moves forward, I hope you'll strongly consider taking this opportunity to match Vite by decoupling commands from modes, so that vite build --mode development and vite dev --mode production can both work as expected in Remix.

Today Remix docs and internals treat the remix dev command and the NODE_ENV=development mode as if they're interchangeable. For example, it's assumed in many places that build.mode === "development" means HMR should be enabled:

remix/packages/remix-dev/CHANGELOG.md

Lines 70 to 72 in 051d4b9

	- Detect built mode via `build.mode` ([#6964](https://github.com/remix-run/remix/pull/6964))
	- Prevents mode mismatch between built Remix server entry and user-land server
	- Additionally, all runtimes (including non-Node runtimes) can use `build.mode` to determine if HMR should be performed

remix/packages/remix-react/components.tsx

Lines 1037 to 1040 in 051d4b9

	export const LiveReload =
	process.env.NODE_ENV !== "development"
	? () => null
	: function LiveReload({

remix/packages/remix-serve/cli.ts

Lines 104 to 106 in 051d4b9

	if (process.env.NODE_ENV === "development") {
	void broadcastDevReady(build);
	}

As a result, NODE_ENV=development remix build generates builds that contain broken HMR code.

By comparison, with Vite you can apparently run vite dev --mode production (or vite build --mode development) and everything works as expected, since things like HMR are tied to the dev command (via import.meta.hot) as opposed to the production mode.

"Should we suppress stack traces" is a great example of something that should continue to be mode-dependent, so that you could run vite dev --mode production to work on your error pages as they'll appear in production builds. But HMR and broadcastDevReady are great examples of things that should instead become command-dependent.

[pcattori]

Even better is for Remix to internally use config.command === 'serve' to detect if its being run via vite dev. If so, enable <LiveReload />. Obsoletes the need for our only usage of NODE_ENV and would let you run dev in prod mode if you wanted to (and build in dev mode too).

[duailibe]

@pcattori Can that be tree-shaken out of prod builds?

[pcattori]

The config.command === 'serve' check happens within the Vite plugin, not within your app code. So LiveReload would never end up in your prod code and there's nothing to treeshake. Best of all worlds!

[aaronadamsCA]

"Obsoletes the need for NODE_ENV" is music to my ears, thank you.

As a friendly FYI, the Vite docs do specifically recommend guarding HMR API usage with import.meta.hot. Of course I trust your judgment better than mine as to what's right for your use case!

[pcattori]

👍 We're already guarding HMR API usage with import.meta.hot. That specifically refers to the HMR API in the client-side code, which doesn't get changed at all by this.

[AC4G]

Am I the only one confused with the @remix-run/vite package? This package is not available in the npm register or as a github repo. How do I find it then? Or is it still in development and will be published soon?

[sergiodxa]

Yes, this is an RFC, not the documentation, final implementation will most likely differ, unstable version could also change when stabilized so it's possible in the future it will become @remix-run/vite but right now it's still on the @remix-run/dev package.

[JimmayVV]

Being able to point to Remix for our SPA needs (and yes it's a hard "need") and our SSR needs (which we also have) is going to be a game changer. Excited to see this progress.

[patjakubik]

We have SPA built with Vite and served by Express. When it comes to reloading the app on code change, we utilize tsx --watch. However, any changes made in the server restart the app entirely. Can this new approach improve this issue? Additionally, we encountered difficulties with the Vite express middleware. It doesn't work greatly with tunneling like ngrok, as the Vite reloads the app before the server runs after reload. When using ngrok, there are intermittent issues with websockets that are still unclear to me.

[sergiodxa]

If you're using Vite yourself to build a SPA served by Express, how is this related to Remix?

[patjakubik]

@sergiodxa We would like to migrate to Remix once it supports Vite and SPA mode. Apologies for any confusion earlier. Our main concern is whether these new features will improve our current workflow. Can you provide any insights?

[hugo]

With the understanding that Vite support is still experimental, would you like issues reported from testing it, and if so where?

[pcattori]

Report issues through GitHub issues on the remix-run/remix repo and include "Vite" at the beginning of the title so we can make sure to group all the Vite issues together. Thanks!

[smeng9]

Does that mean in the future remix will only be published as a plugin for vite instead of as a framework?

[smeng9]

Does that mean there will be a v3 version for remix soon? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Fireclunge ***@***.***> Sent: Friday, November 3, 2023 10:13:20 PM To: remix-run/remix ***@***.***> Cc: Meng, Shaoyu ***@***.***>; Comment ***@***.***> Subject: Re: [remix-run/remix] Just use vite! (Discussion #7632) Correct. Going forward Remix will strictly be going forward as a Vite plug in only. Serious. — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https://github.com/remix-run/remix/discussions/7632*discussioncomment-7472250__;Iw!!DZ3fjg!4Ez8tXcZa2cmM_Ed4V8FO2mNSpdPyLaJGmjLvMpd49FTWINY7L4jkysJEYxFuRBwjx5kxPUU8dfnDdzDEeEfk-fpIcM$>, or unsubscribe<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AJHAEC5ZGY5YDWCLRPA4ADDYCWXFBAVCNFSM6AAAAAA54DBSGKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TINZSGI2TA__;!!DZ3fjg!4Ez8tXcZa2cmM_Ed4V8FO2mNSpdPyLaJGmjLvMpd49FTWINY7L4jkysJEYxFuRBwjx5kxPUU8dfnDdzDEeEfXEKqdjA$>. You are receiving this because you commented.Message ID: ***@***.***>

[MichaelDeBoey]

Since we already have a v3_* future flag, it's definitely the plan to have a V3 at some point in the future