Dev tools and CLI for React Router
React Router is a multi-strategy router for React bridging the gap from React 18 to React 19. You can use it maximally as a React framework or minimally as a library with your own architecture.
remix-run
react-router@react-router/dev@react-router/node@react-router/cloudflare@react-router/serve@react-router/fs-routes@react-router/devAdded a new react-router.config.ts routeDiscovery option to configure Lazy Route Discovery behavior. (#13451)
/__manifest path:routeDiscovery: { mode: "lazy", manifestPath: "/__manifest" }routeDiscovery: { mode: "lazy", manifestPath: "/custom-manifest" }routeDiscovery: { mode: "initial" }Automatic types for future flags (#13506)
Some future flags alter the way types should work in React Router. Previously, you had to remember to manually opt-in to the new types.
For example, for unstable_middleware:
// react-router.config.ts
// Step 1: Enable middleware
export default {
future: {
unstable_middleware: true,
},
};
// Step 2: Enable middleware types
declare module "react-router" {
interface Future {
unstable_middleware: true; // 👈 Enable middleware types
}
}It was up to you to keep the runtime future flags synced with the types for those future flags. This was confusing and error-prone.
Now, React Router will automatically enable types for future flags. That means you only need to specify the runtime future flag:
// react-router.config.ts
// Step 1: Enable middleware
export default {
future: {
unstable_middleware: true,
},
};
// No step 2! That's it!Behind the scenes, React Router will generate the corresponding declare module into .react-router/types.
Currently this is done in .react-router/types/+register.ts but this is an implementation detail that may change in the future.
Support project root directories without a package.json if it exists in a parent directory (#13472)
When providing a custom Vite config path via the CLI --config/-c flag, default the project root directory to the directory containing the Vite config when not explicitly provided (#13472)
In a routes.ts context, ensure the --mode flag is respected for import.meta.env.MODE (#13485)
Previously, import.meta.env.MODE within a routes.ts context was always "development" for the dev and typegen --watch commands, but otherwise resolved to "production". These defaults are still in place, but if a --mode flag is provided, this will now take precedence.
Ensure consistent project root directory resolution logic in CLI commands (#13472)
When executing react-router.config.ts and routes.ts with vite-node, ensure that PostCSS config files are ignored (#13489)
When extracting critical CSS during development, ensure it's loaded from the client environment to avoid issues with plugins that handle the SSR environment differently (#13503)
When future.unstable_viteEnvironmentApi is enabled, ensure that build.assetsDir in Vite config is respected when environments.client.build.assetsDir is not configured (#13491)
Fix "Status message is not supported by HTTP/2" error during dev when using HTTPS (#13460)
Update config when react-router.config.ts is created or deleted during development. (#12319)
Skip unnecessary routes.ts evaluation before Vite build is started (#13513)
Fix TS2300: Duplicate identifier errors caused by generated types (#13499)
Previously, routes that had the same full path would cause duplicate entries in the generated types for href (.react-router/types/+register.ts), causing type checking errors.
Updated dependencies:
@react-router/node@7.6.0@react-router/serve@7.6.0@react-router/node@7.5.3@react-router/serve@7.5.3@react-router/node@7.5.2@react-router/serve@7.5.2@react-router/node@7.5.1@react-router/serve@7.5.1unstable_subResourceIntegrity future flag that enables generation of an importmap with integrity for the scripts that will be loaded by the browser. (#13163)future.unstable_viteEnvironmentApi is enabled, ensure critical CSS in development works when using a custom Vite base has been configured (#13305)depsOptimizer is required in dev mode errors when using vite-plugin-cloudflare and importing Node.js builtins (#13317)@react-router/node@7.5.0@react-router/serve@7.5.0moduleDetection is set to force (#13267)future.unstable_middleware and future.unstable_splitRouteModules are enabled, split unstable_clientMiddleware route exports into separate chunks when possible (#13210)future.unstable_middleware by ensuring that route modules are only blocking during the middleware phase when the unstable_clientMiddleware has been defined (#13210)@react-router/node@7.4.1@react-router/serve@7.4.1virtual:react-router/server-build module (#13152)future.unstable_splitRouteModules is set to "enforce", allow both splittable and unsplittable root route exports since it's always in a single chunk. (#13238)future.unstable_viteEnvironmentApi is enabled, allow plugins that override the default SSR environment (such as @cloudflare/vite-plugin) to be placed before or after the React Router plugin. (#13183)configureServer and/or configurePreviewServer hooks (#13184)@react-router/node@7.4.0@react-router/serve@7.4.0Fix support for custom client build.rollupOptions.output.entryFileNames (#13098)
Fix usage of prerender option when serverBundles option has been configured or provided by a preset, e.g. vercelPreset from @vercel/react-router (#13082)
Fix support for custom build.assetsDir (#13077)
Remove unused dependencies (#13134)
Stub all routes except root in "SPA Mode" server builds to avoid issues when route modules or their dependencies import non-SSR-friendly modules (#13023)
Fix errors with future.unstable_viteEnvironmentApi when the ssr environment has been configured by another plugin to be a custom Vite.DevEnvironment rather than the default Vite.RunnableDevEnvironment (#13008)
Remove unused Vite file system watcher (#13133)
Fix support for custom SSR build input when serverBundles option has been configured (#13107)
Note that for consumers using the future.unstable_viteEnvironmentApi and serverBundles options together, hyphens are no longer supported in server bundle IDs since they also need to be valid Vite environment names.
Fix dev server when using HTTPS by stripping HTTP/2 pseudo headers from dev server requests (#12830)
Lazy load Cloudflare platform proxy on first dev server request when using the cloudflareDevProxy Vite plugin to avoid creating unnecessary workerd processes (#13016)
When future.unstable_viteEnvironmentApi is enabled and the ssr environment has optimizeDeps.noDiscovery disabled, define optimizeDeps.entries and optimizeDeps.include (#13007)
Fix duplicated entries in typegen for layout routes and their corresponding index route (#13140)
Updated dependencies:
@react-router/node@7.3.0@react-router/serve@7.3.0Generate a "SPA fallback" HTML file for scenarios where applications are prerendering the / route with ssr:false (#12948)
ssr:false without a prerender config, this is considered "SPA Mode" and the generated index.html file will only render down to the root route and will be able to hydrate for any valid application pathssr:false with a prerender config but do not include the / path (i.e., prerender: ['/blog/post']), then we still generate a "SPA Mode" index.html file that can hydrate for any path in the applicationssr:false and included the / path in your prerender config, we would prerender the / route into index.html as a non-SPA page__spa-fallback.html that will allow you to hydrate for any non-prerendered pathsssr:false app and serve the others as a SPAnpx sirv-cli build/client --single __spa-fallback.htmlAllow a loader in the root route in SPA mode because it can be called/server-rendered at build time (#12948)
Route.HydrateFallbackProps now also receives loaderDataHydrateFallback is rendering while children routes are loadingundefined if the HydrateFallback is rendering because the route has it's own hydrating clientLoaderindex.htmlNew type-safe href utility that guarantees links point to actual paths in your app (#13012)
import { href } from "react-router";
export default function Component() {
const link = href("/blog/:slug", { slug: "my-first-post" });
return (
<main>
<Link to={href("/products/:id", { id: "asdf" })} />
<NavLink to={href("/:lang?/about", { lang: "en" })} />
</main>
);
}Handle custom envDir in Vite config (#12969)
Fix typegen for repeated params (#13012)
In React Router, path parameters are keyed by their name.
So for a path pattern like /a/:id/b/:id?/c/:id, the last :id will set the value for id in useParams and the params prop.
For example, /a/1/b/2/c/3 will result in the value { id: 3 } at runtime.
Previously, generated types for params incorrectly modeled repeated params with an array.
So /a/1/b/2/c/3 generated a type like { id: [1,2,3] }.
To be consistent with runtime behavior, the generated types now correctly model the "last one wins" semantics of path parameters.
So /a/1/b/2/c/3 now generates a type like { id: 3 }.
Fix CLI parsing to allow argumentless npx react-router usage (#12925)
Fix ArgError: unknown or unexpected option: --version when running react-router --version (#13012)
Skip action-only resource routes when using prerender:true (#13004)
Enhance invalid export detection when using ssr:false (#12948)
headers/action are prohibited in all routes with ssr:false because there will be no runtime server on which to run themloader functions are more nuanced and depend on whether a given route is prerenderedssr:false without a prerender config, only the root route can have a loaderindex.html file with the root route HydrateFallback so it is capable of hydrating for any path in your application - therefore we can only call a root route loader at build timessr:false with a prerender config, you can export a loader from routes matched by one of the prerender paths because those routes will be server rendered at build timeloader from a route that is never matched by a prerender path will throw a build time error because there will be no runtime server to ever run the loaderLimit prerendered resource route .data files to only the target route (#13004)
Add unstable support for splitting route modules in framework mode via future.unstable_splitRouteModules (#11871)
Fix prerendering of binary files (#13039)
Add future.unstable_viteEnvironmentApi flag to enable experimental Vite Environment API support (#12936)
Disable Lazy Route Discovery for all ssr:false apps and not just "SPA Mode" because there is no runtime server to serve the search-param-configured __manifest requests (#12894)
ssr:false and no prerender config but we realized it should apply to all ssr:false apps, including those prerendering multiple pagesprerender scenarios we would prerender the /__manifest file assuming the static file server would serve it but that makes some unneccesary assumptions about the static file server behaviorsUpdated dependencies:
@react-router/node@7.2.0@react-router/serve@7.2.0@react-router/node@7.1.5@react-router/serve@7.1.5unstable_optimizeDeps future flag. (#12637)@react-router/node@7.1.4@react-router/serve@7.1.4reveal and routes CLI commands (#12745)@react-router/node@7.1.3@react-router/serve@7.1.3module-sync server condition when enabled in the runtime. This fixes React context mismatches (e.g. useHref() may be used only in the context of a <Router> component.) during development on Node 22.10.0+ when using libraries that have a peer dependency on React Router. (#12729)@react-router/node@7.1.2@react-router/serve@7.1.25b1ca202f)@react-router/node@7.1.1@react-router/serve@7.1.1Properly initialize NODE_ENV if not already set for compatibility with React 19 (#12578)
Remove the leftover/unused abortDelay prop from ServerRouter and update the default entry.server.tsx to use the new streamTimeout value for Single Fetch (#12478)
abortDelay functionality was removed in v7 as it was coupled to the defer implementation from Remix v2, but this removal of this prop was missedentry.server file, it's likely your app is not aborting streams as you would expect and you will need to adopt the new streamTimeout value introduced with Single FetchUpdated dependencies:
@react-router/node@7.1.0@react-router/serve@7.1.0Support moduleResolution Node16 and NodeNext (#12440)
Generate wide matches and params types for current route and child routes (#12397)
At runtime, matches includes child route matches and params include child route path parameters.
But previously, we only generated types for parent routes in matches; for params, we only considered the parent routes and the current route.
To align our generated types more closely to the runtime behavior, we now generate more permissive, wider types when accessing child route information.
Updated dependencies:
@react-router/node@7.0.2@react-router/serve@7.0.2@react-router/node@7.0.1@react-router/serve@7.0.1For Remix consumers migrating to React Router, the vitePlugin and cloudflareDevProxyVitePlugin exports have been renamed and moved. (#11904)
-import {
- vitePlugin as remix,
- cloudflareDevProxyVitePlugin,
-} from "@remix/dev";
+import { reactRouter } from "@react-router/dev/vite";
+import { cloudflareDevProxy } from "@react-router/dev/vite/cloudflare";Remove single fetch future flag. (#11522)
update minimum node version to 18 (#11690)
Add exports field to all packages (#11675)
node package no longer re-exports from react-router (#11702)
For Remix consumers migrating to React Router who used the Vite plugin's buildEnd hook, the resolved reactRouterConfig object no longer contains a publicPath property since this belongs to Vite, not React Router. (#11575)
For Remix consumers migrating to React Router, the Vite plugin's manifest option has been removed. (#11573)
The manifest option been superseded by the more powerful buildEnd hook since it's passed the buildManifest argument. You can still write the build manifest to disk if needed, but you'll most likely find it more convenient to write any logic depending on the build manifest within the buildEnd hook itself.
If you were using the manifest option, you can replace it with a buildEnd hook that writes the manifest to disk like this:
// react-router.config.ts
import type { Config } from "@react-router/dev/config";
import { writeFile } from "node:fs/promises";
export default {
async buildEnd({ buildManifest }) {
await writeFile(
"build/manifest.json",
JSON.stringify(buildManifest, null, 2),
"utf-8"
);
},
} satisfies Config;Consolidate types previously duplicated across @remix-run/router, @remix-run/server-runtime, and @remix-run/react now that they all live in react-router (#12177)
LoaderFunction, LoaderFunctionArgs, ActionFunction, ActionFunctionArgs, DataFunctionArgs, RouteManifest, LinksFunction, Route, EntryRouteRouteManifest type used by the "remix" code is now slightly stricter because it is using the former @remix-run/router RouteManifestRecord<string, Route> -> Record<string, Route | undefined>AppData type in favor of inlining unknown in the few locations it was usedServerRuntimeMeta* types in favor of the Meta* types they were duplicated fromUpdate default isbot version to v5 and drop support for isbot@3 (#11770)
isbot@4 or isbot@5 in your package.json:isbot@3 in your package.json and you have your own entry.server.tsx file in your repoisbot@5 independent of the React Router v7 upgradeisbot@3 in your package.json and you do not have your own entry.server.tsx file in your repoisbot@5 in your package.jsonDrop support for Node 18, update minimum Node vestion to 20 (#12171)
installGlobals() as this should no longer be necessaryFor Remix consumers migrating to React Router, Vite manifests (i.e. .vite/manifest.json) are now written within each build subdirectory, e.g. build/client/.vite/manifest.json and build/server/.vite/manifest.json instead of build/.vite/client-manifest.json and build/.vite/server-manifest.json. This means that the build output is now much closer to what you'd expect from a typical Vite project. (#11573)
Originally the Remix Vite plugin moved all Vite manifests to a root-level build/.vite directory to avoid accidentally serving them in production, particularly from the client build. This was later improved with additional logic that deleted these Vite manifest files at the end of the build process unless Vite's build.manifest had been enabled within the app's Vite config. This greatly reduced the risk of accidentally serving the Vite manifests in production since they're only present when explicitly asked for. As a result, we can now assume that consumers will know that they need to manage these additional files themselves, and React Router can safely generate a more standard Vite build output.
Params, loader data, and action data as props for route component exports (#11961)
export default function Component({ params, loaderData, actionData }) {}
export function HydrateFallback({ params }) {}
export function ErrorBoundary({ params, loaderData, actionData }) {}Remove internal entry.server.spa.tsx implementation (#11681)
Add prefix route config helper to @react-router/dev/routes (#12094)
React Router now generates types for each of your route modules.
You can access those types by importing them from ./+types.<route filename without extension>.
For example:
// app/routes/product.tsx
import type * as Route from "./+types.product";
export function loader({ params }: Route.LoaderArgs) {}
export default function Component({ loaderData }: Route.ComponentProps) {}This initial implementation targets type inference for:
Params : Path parameters from your routing config in routes.ts including file-based routingLoaderData : Loader data from loader and/or clientLoader within your route moduleActionData : Action data from action and/or clientAction within your route moduleIn the future, we plan to add types for the rest of the route module exports: meta, links, headers, shouldRevalidate, etc.
We also plan to generate types for typesafe Links:
<Link to="/products/:id" params={{ id: 1 }} />
// ^^^^^^^^^^^^^ ^^^^^^^^^
// typesafe `to` and `params` based on the available routes in your appCheck out our docs for more:
development exports condition. (#12269)index.html for hydration (#12268)@react-router/serve@7.0.0@react-router/node@7.0.0New future.unstable_singleFetch flag (#8773)
turbo-stream so Date's will become Date through useLoaderData()Promise's without needing to use defer() - including nested Promise'sdefer utility<RemixServer abortDelay> is no longer used. Instead, you should export const streamTimeout from entry.server.tsx and the remix server runtime will use that as the delay to abort the streamed responserenderToPipeableStream. You should always ensure that react is aborted afer the stream is aborted so that abort rejections can be flushed downfuture.unstable_skipActionErrorRevalidation flag) - you can return a 2xx to opt-into revalidation or use shouldRevalidategetDependenciesToBundle resolution in monorepos (#8848)@remix-run/node@2.9.0@remix-run/server-runtime@2.9.0remix reveal and remix routes CLI commands (#8916)--help output (#8939)build.sourcemap option in Vite config (#8965)server.fs.allow option without a client entry file (#8966)@remix-run/node@2.8.1@remix-run/server-runtime@2.8.1viteConfig to Remix Vite plugin's buildEnd hook (#8885)Layout as browser safe route export in esbuild compiler (#8842)serverBundles issue where multiple browser manifests are generated (#8864)build.assetsDir option (#8843)@remix-run/node@2.8.0@remix-run/server-runtime@2.8.0.css?url imports (#8829)@remix-run/node@2.7.2@remix-run/server-runtime@2.7.2@remix-run/node@2.7.1@remix-run/server-runtime@2.7.1Allow an optional Layout export from the root route (#8709)
Vite: Cloudflare Proxy as a Vite plugin (#8749)
This is a breaking change for projects relying on Cloudflare support from the unstable Vite plugin
The Cloudflare preset (unstable_cloudflarePreset) as been removed and replaced with a new Vite plugin:
import {
unstable_vitePlugin as remix,
- unstable_cloudflarePreset as cloudflare,
+ cloudflareDevProxyVitePlugin as remixCloudflareDevProxy,
} from "@remix-run/dev";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [
+ remixCloudflareDevProxy(),
+ remix(),
- remix({
- presets: [cloudflare()],
- }),
],
- ssr: {
- resolve: {
- externalConditions: ["workerd", "worker"],
- },
- },
});remixCloudflareDevProxy must come before the remix plugin so that it can override Vite's dev server middleware to be compatible with Cloudflare's proxied environment.
Because it is a Vite plugin, remixCloudflareDevProxy can set ssr.resolve.externalConditions to be workerd-compatible for you.
remixCloudflareDevProxy accepts a getLoadContext function that replaces the old getRemixDevLoadContext.
If you were using a nightly version that required getBindingsProxy or getPlatformProxy, that is no longer required.
Any options you were passing to getBindingsProxy or getPlatformProxy should now be passed to remixCloudflareDevProxy instead.
This API also better aligns with future plans to support Cloudflare with a framework-agnostic Vite plugin that makes use of Vite's (experimental) Runtime API.
Vite: Stabilize the Remix Vite plugin, Cloudflare preset, and all related types by removing all unstable_ / Unstable_ prefixes. (#8713)
While this is a breaking change for existing Remix Vite plugin consumers, now that the plugin has stabilized, there will no longer be any breaking changes outside of a major release. Thank you to all of our early adopters and community contributors for helping us get here! 🙏
Vite: Stabilize "SPA Mode" by renaming the Remix vite plugin config from unstable_ssr -> ssr (#8692)
Vite: Add a new basename option to the Vite plugin, allowing users to set the internal React Router basename in order to to serve their applications underneath a subpath (#8145)
Vite: fix server exports dead-code elimination for routes outside of app directory (#8795)
Always prepend DOCTYPE in SPA mode entry.server.tsx, can opt out via remix reveal (#8725)
Fix build issue in SPA mode when using a basename (#8720)
Vite: Validate that the MDX Rollup plugin, if present, is placed before Remix in Vite config (#8690)
Vite: reliably detect non-root routes in Windows (#8806)
Sometimes route file will be unnormalized Windows path with \ instead of /.
Vite: Pass remixUserConfig to preset remixConfig hook (#8797)
Vite: Fix issue resolving critical CSS during development when the current working directory differs from the project root (#8752)
Vite: Ensure CSS file URLs that are only referenced in the server build are available on the client (#8796)
Vite: Require version 5.1.0 to support .css?url imports (#8723)
Fix type error in Remix config for synchronous routes function (#8745)
Vite: Support Vite v5.1.0's .css?url imports (#8684)
Always ignore route files starting with . (#8801)
Vite: Enable use of vite preview to preview Remix SPA applications (#8624)
npm run start has been renamed to npm run preview which uses vite preview instead of a standalone HTTP server such as http-server or serv-cliVite: Remove the ability to pass publicPath as an option to the Remix vite plugin (#8145)
publicPathbase config so we now set the Remix publicPath from the Vite base configVite: Fix issue where client route file requests fail if search params have been parsed and serialized before reaching the Remix Vite plugin (#8740)
Vite: Enable HMR for .md and .mdx files (#8711)
Updated dependencies:
@remix-run/server-runtime@2.7.0@remix-run/node@2.7.0future.v3_throwAbortReason flag to throw request.signal.reason when a request is aborted instead of an Error such as new Error("query() call aborted: GET /path") (#8251)Vite: Add manifest option to Vite plugin to enable writing a .remix/manifest.json file to the build directory (#8575)
This is a breaking change for consumers of the Vite plugin's "server bundles" feature.
The build/server/bundles.json file has been superseded by the more general build/.remix/manifest.json. While the old server bundles manifest was always written to disk when generating server bundles, the build manifest file must be explicitly enabled via the manifest option.
Vite: Provide Unstable_ServerBundlesFunction and Unstable_VitePluginConfig types (#8654)
Vite: add --sourcemapClient and --sourcemapServer flags to remix vite:build (#8613)
--sourcemapClient
--sourcemapClient=inline
--sourcemapClient=hidden
--sourcemapServer
--sourcemapServer=inline
--sourcemapServer=hidden
See https://vitejs.dev/config/build-options.html#build-sourcemap
Vite: Validate IDs returned from the serverBundles function to ensure they only contain alphanumeric characters, hyphens and underscores (#8598)
Vite: fix "could not fast refresh" false alarm (#8580)
HMR is already functioning correctly but was incorrectly logging that it "could not fast refresh" on internal client routes.
Now internal client routes correctly register Remix exports like meta for fast refresh,
which removes the false alarm.
Vite: Cloudflare Pages support (#8531)
To get started with Cloudflare, you can use the [unstable-vite-cloudflare][template-vite-cloudflare] template:
shellscript nonumber
npx create-remix@latest --template remix-run/remix/templates/unstable-vite-cloudflare
Or read the new docs at Future > Vite > Cloudflare and Future > Vite > Migrating > Migrating Cloudflare Functions.
Vite: Remove undocumented backwards compatibility layer for Vite v4 (#8581)
Vite: rely on Vite plugin ordering (#8627)
This is a breaking change for projects using the unstable Vite plugin.
The Remix plugin expects to process JavaScript or TypeScript files, so any transpilation from other languages must be done first. For example, that means putting the MDX plugin before the Remix plugin:
import mdx from "@mdx-js/rollup";
import { unstable_vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [
+ mdx(),
remix()
- mdx(),
],
});Previously, the Remix plugin misused enforce: "post" from Vite's plugin API to ensure that it ran last.
However, this caused other unforeseen issues.
Instead, we now rely on standard Vite semantics for plugin ordering.
The official Vite React SWC plugin also relies on plugin ordering for MDX.
Vite: Add presets option to ease integration with different platforms and tools. (#8514)
Vite: Remove interop with <LiveReload />, rely on <Scripts /> instead (#8636)
This is a breaking change for projects using the unstable Vite plugin.
Vite provides a robust client-side runtime for development features like HMR,
making the <LiveReload /> component obsolete.
In fact, having a separate dev scripts component was causing issues with script execution order.
To work around this, the Remix Vite plugin used to override <LiveReload /> into a bespoke
implementation that was compatible with Vite.
Instead of all this indirection, now the Remix Vite plugin instructs the <Scripts /> component
to automatically include Vite's client-side runtime and other dev-only scripts.
import {
- LiveReload,
Outlet,
Scripts,
}
export default function App() {
return (
<html>
<head>
</head>
<body>
<Outlet />
<Scripts />
- <LiveReload />
</body>
</html>
)
}Vite: Add buildEnd hook (#8620)
Vite: add dev load context option to Cloudflare preset (#8649)
Vite: Add mode field into generated server build (#8539)
Vite: Only write Vite manifest files if build.manifest is enabled within the Vite config (#8599)
This is a breaking change for consumers of Vite's manifest.json files.
To explicitly enable generation of Vite manifest files, you must set build.manifest to true in your Vite config.
export default defineConfig({
build: { manifest: true },
// ...
});Vite: reduce network calls for route modules during HMR (#8591)
Vite: Add new buildDirectory option with a default value of "build". This replaces the old assetsBuildDirectory and serverBuildDirectory options which defaulted to "build/client" and "build/server" respectively. (#8575)
This is a breaking change for consumers of the Vite plugin that were using the assetsBuildDirectory and serverBuildDirectory options.
The Remix Vite plugin now builds into a single directory containing client and server directories. If you've customized your build output directories, you'll need to migrate to the new buildDirectory option, e.g.
import { unstable_vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [
remix({
- serverBuildDirectory: "dist/server",
- assetsBuildDirectory: "dist/client",
+ buildDirectory: "dist",
})
],
});Vite: Remove unstable prefix from serverBundles option. (#8596)
Vite: Write Vite manifest files to build/.vite directory rather than being nested within build/client and build/server directories. (#8599)
This is a breaking change for consumers of Vite's manifest.json files.
Vite manifest files are now written to the Remix build directory. Since all Vite manifests are now in the same directory, they're no longer named manifest.json. Instead, they're named build/.vite/client-manifest.json and build/.vite/server-manifest.json, or build/.vite/server-{BUNDLE_ID}-manifest.json when using server bundles.
Updated dependencies:
@remix-run/server-runtime@2.6.0@remix-run/node@2.6.0isSpaMode to @remix-run/dev/server-build virtual module (#8492)<!DOCTYPE html> if not present to fix quirks mode warnings for SPA template (#8495)remix vite:build --profile to generate a .cpuprofile that can be shared or uploaded to speedscope.appp + enter to start a new profiling session or stop the current sessionremix vite:dev --profile to initialize the dev server with a running profiling session@remix-run/node@2.5.1@remix-run/server-runtime@2.5.1Add unstable support for "SPA Mode" (#8457)
You can opt into SPA Mode by setting unstable_ssr: false in your Remix Vite plugin config:
// vite.config.ts
import { unstable_vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [remix({ unstable_ssr: false })],
});Development in SPA Mode is just like a normal Remix app, and still uses the Remix dev server for HMR/HDR:
remix vite:devBuilding in SPA Mode will generate an index.html file in your client assets directory:
remix vite:buildTo run your SPA, you serve your client assets directory via an HTTP server:
npx http-server build/clientFor more information, please refer to the SPA Mode docs.
Add unstable_serverBundles option to Vite plugin to support splitting server code into multiple request handlers. (#8332)
This is an advanced feature designed for hosting provider integrations. When compiling your app into multiple server bundles, there will need to be a custom routing layer in front of your app directing requests to the correct bundle. This feature is currently unstable and only designed to gather early feedback.
Example usage:
import { unstable_vitePlugin as remix } from "@remix-run/dev";
import { defineConfig } from "vite";
export default defineConfig({
plugins: [
remix({
unstable_serverBundles: ({ branch }) => {
const isAuthenticatedRoute = branch.some(
(route) => route.id === "routes/_authenticated"
);
return isAuthenticatedRoute ? "authenticated" : "unauthenticated";
},
}),
],
});Fix issue with isbot v4 released on 1/1/2024 (#8415)
remix dev will now add "isbot": "^4" to package.json instead of using latestentry.server files to work with both isbot@3 and isbot@4 for backwards-compatibility with Remix apps that have pinned isbot to v3isbot@4 moving forward via create-remixVite: Fix HMR issues when altering exports for non-rendered routes (#8157)
Vite: Default NODE_ENV to "production" when running remix vite:build command (#8405)
Vite: Remove Vite plugin config option serverBuildPath in favor of separate serverBuildDirectory and serverBuildFile options (#8332)
Vite: Loosen strict route exports restriction, reinstating support for non-Remix route exports (#8420)
Updated dependencies:
@remix-run/server-runtime@2.5.0@remix-run/node@2.5.0Vite: Error messages when .server files are referenced by client (#8267)
.server module from client code resulted in an error message like:The requested module '/app/models/answer.server.ts' does not provide an export named 'isDateType'answer.server.ts does provide the isDateType export, but Remix was replacing .server modules with empty modules (export {}) for the client build.server module is referenced from client code and includes dedicated error messages depending on whether the import occurs in a route or a non-route moduleRemove unstable_viteServerBuildModuleId in favor of manually referencing virtual module name "virtual:remix/server-build". (#8264)
This is a breaking change for projects using the unstable Vite plugin with a custom server.
This change was made to avoid issues where @remix-run/dev could be inadvertently required in your server's production dependencies.
Instead, you should manually write the virtual module name "virtual:remix/server-build" when calling ssrLoadModule in development.
-import { unstable_viteServerBuildModuleId } from "@remix-run/dev";
// ...
app.all(
"*",
createRequestHandler({
build: vite
- ? () => vite.ssrLoadModule(unstable_viteServerBuildModuleId)
+ ? () => vite.ssrLoadModule("virtual:remix/server-build")
: await import("./build/server/index.js"),
})
);Vite: Fix errors for non-existent index.html importer (#8353)
Add vite:dev and vite:build commands to the Remix CLI. (#8211)
In order to handle upcoming Remix features where your plugin options can impact the number of Vite builds required, you should now run your Vite dev and build processes via the Remix CLI.
{
"scripts": {
- "dev": "vite dev",
- "build": "vite build && vite build --ssr"
+ "dev": "remix vite:dev",
+ "build": "remix vite:build"
}
}Vite: Preserve names for exports from .client modules (#8200)
Unlike .server modules, the main idea is not to prevent code from leaking into the server build
since the client build is already public. Rather, the goal is to isolate the SSR render from client-only code.
Routes need to import code from .client modules without compilation failing and then rely on runtime checks
or otherwise ensure that execution only happens within a client-only context (e.g. event handlers, useEffect).
Replacing .client modules with empty modules would cause the build to fail as ESM named imports are statically analyzed.
So instead, we preserve the named export but replace each exported value with undefined.
That way, the import is valid at build time and standard runtime checks can be used to determine if the
code is running on the server or client.
Disable watch mode in Vite child compiler during build (#8342)
Vite: Show warning when source maps are enabled in production build (#8222)
Updated dependencies:
@remix-run/server-runtime@2.4.1@remix-run/node@2.4.1Vite: exclude modules within .server directories from client build (#8154)
Add support for clientLoader/clientAction/HydrateFallback route exports (RFC) (#8173)
Remix now supports loaders/actions that run on the client (in addition to, or instead of the loader/action that runs on the server). While we still recommend server loaders/actions for the majority of your data needs in a Remix app - these provide some levers you can pull for more advanced use-cases such as:
localStorage)IndexedDB)By default, clientLoader will not run on hydration, and will only run on subsequent client side navigations.
If you wish to run your client loader on hydration, you can set clientLoader.hydrate=true to force Remix to execute it on initial page load. Keep in mind that Remix will still SSR your route component so you should ensure that there is no new required data being added by your clientLoader.
If your clientLoader needs to run on hydration and adds data you require to render the route component, you can export a HydrateFallback component that will render during SSR, and then your route component will not render until the clientLoader has executed on hydration.
clientAction is simpler than clientLoader because it has no hydration use-cases. clientAction will only run on client-side navigations.
For more information, please refer to the clientLoader and clientAction documentation.
Vite: Strict route exports (#8171)
With Vite, Remix gets stricter about which exports are allowed from your route modules. Previously, the Remix compiler would allow any export from routes. While this was convenient, it was also a common source of bugs that were hard to track down because they only surfaced at runtime.
For more, see https://remix.run/docs/en/main/future/vite#strict-route-exports
Add a new future.v3_relativeSplatPath flag to implement a breaking bug fix to relative routing when inside a splat route. For more information, please see the React Router 6.21.0 Release Notes and the useResolvedPath docs. (#8216)
Upgrade Vite peer dependency range to v5 (#8172)
Support HMR for routes with handle export in Vite dev (#8022)
Fix flash of unstyled content for non-Express custom servers in Vite dev (#8076)
Bundle CSS imported in client entry file in Vite plugin (#8143)
Change Vite build output paths to fix a conflict between how Vite and the Remix compiler each manage the public directory. (#8077)
This is a breaking change for projects using the unstable Vite plugin.
The server is now compiled into build/server rather than build, and the client is now compiled into build/client rather than public.
For more information on the changes and guidance on how to migrate your project, refer to the updated Remix Vite documentation.
Remove undocumented legacyCssImports option from Vite plugin due to issues with ?url imports of CSS files not being processed correctly in Vite (#8096)
Vite: fix access to default entry.{client,server}.tsx within pnpm workspace on Windows (#8057)
Remove unstable_createViteServer and unstable_loadViteServerBuild which were only minimal wrappers around Vite's createServer and ssrLoadModule functions when using a custom server. (#8120)
This is a breaking change for projects using the unstable Vite plugin with a custom server.
Instead, we now provide unstable_viteServerBuildModuleId so that custom servers interact with Vite directly rather than via Remix APIs, for example:
-import {
- unstable_createViteServer,
- unstable_loadViteServerBuild,
-} from "@remix-run/dev";
+import { unstable_viteServerBuildModuleId } from "@remix-run/dev";Creating the Vite server in middleware mode:
const vite =
process.env.NODE_ENV === "production"
? undefined
- : await unstable_createViteServer();
+ : await import("vite").then(({ createServer }) =>
+ createServer({
+ server: {
+ middlewareMode: true,
+ },
+ })
+ );Loading the Vite server build in the request handler:
app.all(
"*",
createRequestHandler({
build: vite
- ? () => unstable_loadViteServerBuild(vite)
+ ? () => vite.ssrLoadModule(unstable_viteServerBuildModuleId)
: await import("./build/server/index.js"),
})
);Pass request handler errors to vite.ssrFixStacktrace in Vite dev to ensure stack traces correctly map to the original source code (#8066)
Vite: Preserve names for exports from .client imports (#8200)
Unlike .server modules, the main idea is not to prevent code from leaking into the server build
since the client build is already public. Rather, the goal is to isolate the SSR render from client-only code.
Routes need to import code from .client modules without compilation failing and then rely on runtime checks
to determine if the code is running on the server or client.
Replacing .client modules with empty modules would cause the build to fail as ESM named imports are statically analyzed.
So instead, we preserve the named export but replace each exported value with an empty object.
That way, the import is valid at build time and the standard runtime checks can be used to determine if then
code is running on the server or client.
Add @remix-run/node to Vite's optimizeDeps.include array (#8177)
Improve Vite plugin performance (#8121)
server.preTransformRequests in Vite child compiler since it's only used to process route modulesRemove automatic global Node polyfill installation from the built-in Vite dev server and instead allow explicit opt-in. (#8119)
This is a breaking change for projects using the unstable Vite plugin without a custom server.
If you're not using a custom server, you should call installGlobals in your Vite config instead.
import { unstable_vitePlugin as remix } from "@remix-run/dev";
+import { installGlobals } from "@remix-run/node";
import { defineConfig } from "vite";
+installGlobals();
export default defineConfig({
plugins: [remix()],
});Vite: Errors at build-time when client imports .server default export (#8184)
Remix already stripped .server file code before ensuring that server code never makes it into the client. That results in errors when client code tries to import server code, which is exactly what we want! But those errors were happening at runtime for default imports. A better experience is to have those errors happen at build-time so that you guarantee that your users won't hit them.
Fix request instanceof Request checks when using Vite dev server (#8062)
Updated dependencies:
@remix-run/server-runtime@2.4.0@remix-run/node@2.4.0nonce prop on LiveReload component in Vite dev (#8014)public directory in Vite build (#8039)assetsBuildDirectory was deeply nested within the public directory@remix-run/node@2.3.1@remix-run/server-runtime@2.3.1LiveReload component after Scripts in Vite dev (#7919).jsx files without manual React import in Vite (#7888)LiveReload component in Vite dev (#7919)development and production modes are present, e.g. @mdx-js/rollup. (#7911)process.env.NODE_ENV values other than "development" in Vite dev (#7980)/@fs (#7913)server.fs.allow.@remix-run/react (#7926)node_modules.Error: You must render this element inside a <Remix> element.defer in Vite dev server (#7842)8cd31d65)process.env from .env files on the server in Vite dev (#7958)FutureConfig type (#7895)@remix-run/server-runtime@2.3.0@remix-run/node@2.3.0remix build 👉 vite build && vite build --ssrremix dev 👉 vite devfuture.v3_fetcherPersist flag to change the persistence behavior of fetchers. Instead of being immediately cleaned up when unmounted in the UI, fetchers will persist until they return to an idle state (RFC) (#7704)@remix-run/server-runtime@2.2.0@remix-run/node@2.2.0@remix-run/server-runtime@2.1.0getDependenciesToBundle to handle ESM packages without main exports (#7272)package.json in their exports field so that their path can be resolvedserverBuildPath extension is .cjs (#7180)@remix-run/server-runtime@2.0.1create-remix CLI has been rewritten to feature a cleaner interface, Git repo initialization and optional remix.init script execution. The interactive template prompt and official Remix stack/template shorthands have also been removed so that community/third-party templates are now on a more equal footing. (#6887)create-remix has been moved out of the Remix CLI since it's not intended for use within an existing Remix applicationremix create command is no longer available.remix.config.js via the postcss:false and/or tailwind:false flagsawait to be used within a Remix appserverNodeBuiltinsPolyfill and browserNodeBuiltinsPolyfill configs (#7269)v2_errorBoundary flag and CatchBoundary implementation (#6906)v2_normalizeFormMethod future flag - all formMethod values will be normalized in v2 (#6875)v2_routeConvention flag - the flat route file convention is now standard (#6969)v2_headers flag - it is now the default behavior to use the deepest headers function in the route tree (#6979)meta API now defaults to the new "V2 Meta" API (#6958)serverModuleFormat: "esm" and update remix-serve to use dynamic import to support ESM and CJS build outputs (#6949)serverBuildTarget config option (#6896)REMIX_DEV_HTTP_ORIGIN env var - use REMIX_DEV_ORIGIN instead (#6963)devServerBroadcastDelay config option (#7063)devServerPort option - use --port / dev.port instead (#7078)REMIX_DEV_SERVER_WS_PORT env var - use remix dev's '--port / port option instead (#6965)isTypeScript to remix.init script (#7099)replace-remix-magic-imports codemod (#6899)--no-restart/restart cli args/flags - use --manual/manual instead (#6962)--scheme/scheme and --host/host cli args/flags - use REMIX_DEV_ORIGIN instead (#6962)future.v2_dev flag in remix.config.js to a root level dev config (#7002)browserBuildDirectory config option (#6900)serverBuildDirectory config option ([#6897](https://github.com/remix-run/remix/pull/- Remove codemod command (#6918)
6897))Removed support for "magic exports" from the remix package. This package can be removed from your package.json and you should update all imports to use the source @remix-run/* packages: (#6895)
- import type { ActionArgs } from "remix";
- import { json, useLoaderData } from "remix";
+ import type { ActionArgs } from "@remix-run/node";
+ import { json } from "@remix-run/node";
+ import { useLoaderData } from "@remix-run/react";remix.config.js (#7048)build.mode (#6964)build.mode to determine if HMR should be performedbun package manager (#7074)The serverNodeBuiltinsPolyfill option (along with the newly added browserNodeBuiltinsPolyfill) now supports defining global polyfills in addition to module polyfills (#7269)
For example, to polyfill Node's Buffer global:
module.exports = {
serverNodeBuiltinsPolyfill: {
globals: {
Buffer: true,
},
// You'll probably need to polyfill the "buffer" module
// too since the global polyfill imports this:
modules: {
buffer: true,
},
},
};Fix importing of PNGs, SVGs, and other assets from packages in node_modules (#6813, #7182)
Decouple the @remix-run/dev package from the contents of the @remix-run/css-bundle package. (#6982)
@remix-run/css-bundle package are now entirely managed by the Remix compiler@remix-run/dev without upgrading @remix-run/css-bundleAllow non-development modes for remix watch (#7117)
Stop remix dev when esbuild is not running (#7158)
Do not interpret JSX in .ts files (#7306)
While JSX is supported in .js files for compatibility with existing apps and libraries,
.ts files should not contain JSX. By not interpreting .ts files as JSX, .ts files
can contain single-argument type generics without needing a comma to disambiguate from JSX:
// this works in .ts files
const id = <T>(x: T) => x;
// ^ single-argument type generic// this doesn't work in .tsx files
const id = <T,>(x: T) => x;
// ^ is this a JSX element? or a single-argument type generic?// this works in .tsx files
const id = <T,>(x: T) => x;
// ^ comma: this is a generic, not a JSX element
const component = <h1>hello</h1>;
// ^ no comma: this is a JSX elementEnhance obsolete flag warning for future.v2_dev if it was an object, and prompt users to lift it to the root dev config (#7427)
Allow decorators in app code (#7176)
Allow JSX in .js files during HMR (#7112)
Kill app server when remix dev terminates (#7280)
Support dependencies that import polyfill packages for Node built-ins via a trailing slash (e.g. importing the buffer package with var Buffer = require('buffer/').Buffer as recommended in their README) (#7198)
Dynamic require of "buffer/" is not supported)Surface errors when PostCSS config is invalid (#7391)
Restart dev server when Remix config changes (#7269)
Remove outdated ESM import warnings (#6916)
Do not trigger rebuilds when .DS_Store changes (#7172)
Remove warnings for stabilized flags: (#6905)
unstable_cssSideEffectImportsunstable_cssModulesunstable_vanillaExtractAllow any mode (NODE_ENV) (#7113)
Replace the deprecated xdm package with @mdx-js/mdx (#4054)
Write a version.txt sentinel file after server build is completely written (#7299)
Updated dependencies:
@remix-run/server-runtime@2.0.0devServerBroadcastDelay and devServerPort config options (#7064)@remix-run/server-runtime@1.19.3proxy-agent to resolve npm audit security vulnerability (#7027)@remix-run/server-runtime@1.19.2@remix-run/server-runtime@1.19.1improved networking options for v2_dev (#6724)
deprecate the --scheme and --host options and replace them with the REMIX_DEV_ORIGIN environment variable
Output esbuild metafiles for bundle analysis (#6772)
Written to server build directory (build/ by default):
metafile.css.jsonmetafile.js.json (browser JS)metafile.server.json (server JS)Metafiles can be uploaded to https://esbuild.github.io/analyze/ for analysis.
Add serverNodeBuiltinsPolyfill config option. In remix.config.js you can now disable polyfills of Node.js built-in modules for non-Node.js server platforms, or opt into a subset of polyfills. (#6814, #6859, #6877)
// Disable all polyfills
exports.serverNodeBuiltinsPolyfill = { modules: {} };
// Enable specific polyfills
exports.serverNodeBuiltinsPolyfill = {
modules: {
crypto: true, // Provide a JSPM polyfill
fs: "empty", // Provide an empty polyfill
},
};ignore missing react-dom/client for react 17 (#6725)
Warn if not using v2_dev (#6818)
Also, rename --no-restart to --manual to match intention and documentation.
--no-restart remains an alias for --manual in v1 for backwards compatibility.
ignore errors when killing already dead processes (#6773)
Always rewrite css-derived assets during builds (#6837)
fix sourcemaps for v2_dev (#6762)
Do not clear screen when dev server starts (#6719)
On some terminal emulators, "clearing" only scrolls the next line to the top. on others, it erases the scrollback.
Instead, let users call clear themselves (clear && remix dev) if
they want to clear.
Updated dependencies:
@remix-run/server-runtime@1.19.0react-dom/client for React 17 (#6725)@remix-run/server-runtime@1.18.1remix dev -c: kill all descendant processes of specified command when restarting (#6663)Architect (AWS Lambda) -> Architect in the create-remix CLI to avoid confusion for other methods of deploying to AWS (i.e., SST) (#6484)esbuild-plugins-node-modules-polyfill to 1.0.16 to ensure that the plugin is cached (#6652)@remix-run/server-runtime@1.18.0esbuild-plugin-polyfill-node with esbuild-plugins-node-modules-polyfill (#6562)@remix-run/css-bundle is detected (#6535)@remix-run/server-runtime@1.17.1built-in tls support (#6483)
New options:
--tls-key / tlsKey: TLS key--tls-cert / tlsCert: TLS CertificateIf both TLS options are set, scheme defaults to https
Install mkcert and create a local CA:
brew install mkcert
mkcert -installThen make sure you inform node about your CA certs:
export NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem"👆 You'll probably want to put that env var in your scripts or .bashrc/.zshrc
Now create key.pem and cert.pem:
mkcert -key-file key.pem -cert-file cert.pem localhostSee mkcert docs for more details.
Finally, pass in the paths to the key and cert via flags:
remix dev --tls-key=key.pem --tls-cert=cert.pemor via config:
module.exports = {
future: {
unstable_dev: {
tlsKey: "key.pem",
tlsCert: "cert.pem",
},
},
};That's all that's needed to set up the Remix Dev Server with TLS.
🚨 Make sure to update your app server for TLS as well.
For example, with express:
import fs from "node:fs";
import https from "node:https";
import express from "express";
const app = express();
// ...code setting up your express app...
const appServer = https.createServer(
{
key: fs.readFileSync("key.pem"),
cert: fs.readFileSync("cert.pem"),
},
app
);
appServer.listen(3000, () => {
console.log("Ready on https://localhost:3000");
});remix-serve does not yet support TLS.
That means this only works for custom app server using the -c flag for now.
Reuse dev server port for WebSocket (Live Reload,HMR,HDR) (#6476)
As a result the webSocketPort/--websocket-port option has been obsoleted.
Additionally, scheme/host/port options for the dev server have been renamed.
Available options are:
| Option | flag | config | default |
| ---------- | ------------------ | ---------------- | --------------------------------- |
| Command | -c / --command | command | remix-serve <server build path> |
| Scheme | --scheme | scheme | http |
| Host | --host | host | localhost |
| Port | --port | port | Dynamically chosen open port |
| No restart | --no-restart | restart: false | restart: true |
Note that scheme/host/port options are for the dev server, not your app server. You probably don't need to use scheme/host/port option if you aren't configuring networking (e.g. for Docker or SSL).
Add caching to PostCSS for regular stylesheets (#6505)
Fix warnings when importing CSS files with future.unstable_dev enabled (#6506)
Fix Tailwind performance issue when postcss.config.js contains plugins: { tailwindcss: {} } and remix.config.js contains both tailwind: true and postcss: true. (#6468)
Note that this was not an issue when the plugin function had been explicitly called, i.e. plugins: [tailwindcss()]. Remix avoids adding the Tailwind plugin to PostCSS if it's already present but we were failing to detect when the plugin function hadn't been called — either because the plugin function itself had been passed, i.e. plugins: [require('tailwindcss')], or the plugin config object syntax had been used, i.e. plugins: { tailwindcss: {} }.
Faster server export removal for routes when unstable_dev is enabled. (#6455)
Also, only render modulepreloads on SSR. Do not render modulepreloads when hydrated.
Add HeadersArgs type to be consistent with loaders/actions/meta and allows for using a function declaration in addition to an arrow function expression (#6247)
import type { HeadersArgs } from "@remix-run/node"; // or cloudflare/deno
export function headers({ loaderHeaders }: HeadersArgs) {
return {
"x-my-custom-thing": loaderHeaders.get("x-my-custom-thing") || "fallback",
};
}better error message when remix-serve is not found (#6477)
restore color for app server output (#6485)
Fix route ranking bug with pathless layout route next to a sibling index route (#4421)
path values since the number of slash-delimited segments counts towards route ranking so the trailing slash incorrectly increases the score for routesSupport sibling pathless layout routes by removing pathless layout routes from the unique route path checks in conventional route generation since they inherently trigger duplicate paths (#4421)
fix dev server crashes caused by ungraceful hdr error handling (#6467)
Updated dependencies:
@remix-run/server-runtime@1.17.0loader change detection for HDR (#6299)PATH envvar so that it works cross-platform (e.g. Windows) (#6310).css.ts/.css.js files with Vanilla Extract if @vanilla-extract/css is installed (#6345)tsconfig.json when running using getConfig (remix dev, remix routes, remix build, etc) (#6156)@remix-run/server-runtime@1.16.1Enable support for CSS Modules, Vanilla Extract and CSS side-effect imports (#6046)
These CSS bundling features were previously only available via future.unstable_cssModules, future.unstable_vanillaExtract and future.unstable_cssSideEffectImports options in remix.config.js, but they have now been stabilized.
In order to use these features, check out our guide to CSS bundling in your project.
Stabilize built-in PostCSS support via the new postcss option in remix.config.js. As a result, the future.unstable_postcss option has also been deprecated. (#5960)
The postcss option is false by default, but when set to true will enable processing of all CSS files using PostCSS if postcss.config.js is present.
If you followed the original PostCSS setup guide for Remix, you may have a folder structure that looks like this, separating your source files from its processed output:
.
├── app
│ └── styles (processed files)
│ ├── app.css
│ └── routes
│ └── index.css
└── styles (source files)
├── app.css
└── routes
└── index.cssAfter you've enabled the new postcss option, you can delete the processed files from app/styles folder and move your source files from styles to app/styles:
.
├── app
│ └── styles (source files)
│ ├── app.css
│ └── routes
│ └── index.cssYou should then remove app/styles from your .gitignore file since it now contains source files rather than processed output.
You can then update your package.json scripts to remove any usage of postcss since Remix handles this automatically. For example, if you had followed the original setup guide:
{
"scripts": {
- "dev:css": "postcss styles --base styles --dir app/styles -w",
- "build:css": "postcss styles --base styles --dir app/styles --env production",
- "dev": "concurrently \"npm run dev:css\" \"remix dev\""
+ "dev": "remix dev"
}
}Stabilize built-in Tailwind support via the new tailwind option in remix.config.js. As a result, the future.unstable_tailwind option has also been deprecated. (#5960)
The tailwind option is false by default, but when set to true will enable built-in support for Tailwind functions and directives in your CSS files if tailwindcss is installed.
If you followed the original Tailwind setup guide for Remix and want to make use of this feature, you should first delete the generated app/tailwind.css.
Then, if you have a styles/tailwind.css file, you should move it to app/tailwind.css.
rm app/tailwind.css
mv styles/tailwind.css app/tailwind.cssOtherwise, if you don't already have an app/tailwind.css file, you should create one with the following contents:
@tailwind base;
@tailwind components;
@tailwind utilities;You should then remove /app/tailwind.css from your .gitignore file since it now contains source code rather than processed output.
You can then update your package.json scripts to remove any usage of tailwindcss since Remix handles this automatically. For example, if you had followed the original setup guide:
{
// ...
"scripts": {
- "build": "run-s \"build:*\"",
+ "build": "remix build",
- "build:css": "npm run generate:css -- --minify",
- "build:remix": "remix build",
- "dev": "run-p \"dev:*\"",
+ "dev": "remix dev",
- "dev:css": "npm run generate:css -- --watch",
- "dev:remix": "remix dev",
- "generate:css": "npx tailwindcss -o ./app/tailwind.css",
"start": "remix-serve build"
}
// ...
}The Remix dev server spins up your app server as a managed subprocess. (#6133) This keeps your development environment as close to production as possible. It also means that the Remix dev server is compatible with any app server.
By default, the dev server will use the Remix App Server, but you opt to use your own app server by specifying the command to run it via the -c/--command flag:
remix dev # uses `remix-serve <serve build path>` as the app server
remix dev -c "node ./server.js" # uses your custom app server at `./server.js`The dev server will:
NODE_ENV=development and warn you if it was previously set to something elseIn order to manage your app server, the dev server needs to be told what server build is currently being used by your app server. This works by having the app server send a "I'm ready!" message with the Remix server build hash as the payload.
This is handled automatically in Remix App Server and is set up for you via calls to broadcastDevReady or logDevReady in the official Remix templates.
If you are not using Remix App Server and your server doesn't call broadcastDevReady, you'll need to call it in your app server after it is up and running.
For example, in an Express server:
// server.js
// <other imports>
import { broadcastDevReady } from "@remix-run/node";
// Path to Remix's server build directory ('build/' by default)
const BUILD_DIR = path.join(process.cwd(), "build");
// <code setting up your express server>
app.listen(3000, () => {
const build = require(BUILD_DIR);
console.log("Ready: http://localhost:" + port);
// in development, call `broadcastDevReady` _after_ your server is up and running
if (process.env.NODE_ENV === "development") {
broadcastDevReady(build);
}
});Options priority order is: 1. flags, 2. config, 3. defaults.
| Option | flag | config | default |
| -------------- | ------------------ | ---------------- | --------------------------------- |
| Command | -c / --command | command | remix-serve <server build path> |
| HTTP(S) scheme | --http-scheme | httpScheme | http |
| HTTP(S) host | --http-host | httpHost | localhost |
| HTTP(S) port | --http-port | httpPort | Dynamically chosen open port |
| Websocket port | --websocket-port | websocketPort | Dynamically chosen open port |
| No restart | --no-restart | restart: false | restart: true |
🚨 The --http-* flags are only used for internal dev server <-> app server communication.
Your app will run on your app server's normal URL.
To set unstable_dev configuration, replace unstable_dev: true with unstable_dev: { <options> }.
For example, to set the HTTP(S) port statically:
// remix.config.js
module.exports = {
future: {
unstable_dev: {
httpPort: 8001,
},
},
};You should only need to use the --http-* flags and --websocket-port flag if you need fine-grain control of what scheme/host/port for the dev server.
If you are setting up SSL or Docker networking, these are the flags you'll want to use.
🚨 Remix will not set up SSL and custom host for you.
The --http-scheme and --http-host flag are for you to tell Remix how you've set things up.
It is your task to set up SSL certificates and host files if you want those features.
--no-restart and require cache purgingIf you want to manage server changes yourself, you can use the --no-restart flag to tell the dev server to refrain from restarting your app server when builds succeed:
remix dev -c "node ./server.js" --no-restartFor example, you could purge the require cache of your app server to keep it running while picking up server changes.
If you do so, you should watch the server build path (build/ by default) for changes and only purge the require cache when changes are detected.
🚨 If you use --no-restart, it is your responsibility to call broadcastDevReady when your app server has picked up server changes.
For example, with chokidar:
// server.dev.js
const BUILD_PATH = path.resolve(__dirname, "build");
const watcher = chokidar.watch(BUILD_PATH);
watcher.on("change", () => {
// 1. purge require cache
purgeRequireCache();
// 2. load updated server build
const build = require(BUILD_PATH);
// 3. tell dev server that this app server is now ready
broadcastDevReady(build);
});url() rules when using CSS Modules, Vanilla Extract and CSS side-effect imports (#5788)devDependencies when running remix dev (#6228)serverModuleFormat default change (#6154)bareImports plugin. (#6181)logDevReady as replacement for platforms that can't initialize async I/O outside of the request response lifecycle. (#6204)@remix-run/server-runtime@1.16.0Added deprecation warning for v2_normalizeFormMethod (#5863)
Added a new future.v2_normalizeFormMethod flag to normalize the exposed useNavigation().formMethod as an uppercase HTTP method to align with the previous useTransition behavior as well as the fetch() behavior of normalizing to uppercase HTTP methods. (#5815)
future.v2_normalizeFormMethod === false,useNavigation().formMethod is lowercaseuseFetcher().formMethod is uppercasefuture.v2_normalizeFormMethod === true:useNavigation().formMethod is uppercaseuseFetcher().formMethod is uppercaseAdded deprecation warning for browserBuildDirectory in remix.config (#5702)
Added deprecation warning for CatchBoundary in favor of future.v2_errorBoundary (#5718)
Added experimental support for Vanilla Extract caching, which can be enabled by setting future.unstable_vanillaExtract: { cache: true } in remix.config. This is considered experimental due to the use of a brand new Vanilla Extract compiler under the hood. In order to use this feature, you must be using at least v1.10.0 of @vanilla-extract/css. (#5735)
Added deprecation warning for serverBuildDirectory in remix.config (#5704)
@remix-run/css-bundle are picked up during HMR (#5823)path.resolve when re-exporting entry.client (#5707).mjs and .cjs extensions when detecting CSS side-effect imports (#5564)react-refresh (#5637)future.v2_meta (#5878)@remix-run/server-runtime@1.15.0@remix-run/server-runtime@1.14.3@remix-run/server-runtime@1.14.2*.ico files (#5430)moduleResolution: "bundler" in tsconfig.json (#5576)serverBuildTarget deprecation warning (#5624)@remix-run/server-runtime@1.14.1unstable_dev future flag to be enabledimport.meta.hot API exposed yetentry.client and entry.server files optional (#4600)Fixes flat route inconsistencies where route.{ext} wasn't always being treated like index.{ext} when used in a folder (#5459)
Route conflict no longer throw errors and instead display a helpful warning that we're using the first one we found.
⚠️ Route Path Collision: "/dashboard"
The following routes all define the same URL, only the first one will be used
🟢️️ routes/dashboard/route.tsx
⭕️️ routes/dashboard.tsx⚠️ Route Path Collision: "/"
The following routes all define the same URL, only the first one will be used
🟢️️ routes/_landing._index.tsx
⭕️️ routes/_dashboard._index.tsx
⭕️ routes/_index.tsxLog errors thrown during initial build in development. (#5441)
Sync FutureConfig interface between packages (#5398)
Add file loader for importing .csv files (#3920)
Updated dependencies:
@remix-run/server-runtime@1.14.0serverBuildTarget in remix.config. See the release notes for v1.13.0 for more information. (#5354)future.unstable_postcss feature flag (#5229)future.unstable_tailwind feature flag (#5229)@remix-run/server-runtime@1.13.0unstable_dev flag. See the release notes for a full description. (#5133)v2_routeConvention on Windows so that new and renamed files are properly included (#5266)remix watch and remix dev (#5228)@remix-run/server-runtime@1.12.0v2_routeConvention that prevented index modules from being recognized for route paths (195291a3d)@remix-run/server-runtime@1.11.1.fbx, .glb, .gltf, .hdr, and .mov files (#5030)unstable_vanillaExtract future flag. IMPORTANT: Features marked with unstable are … unstable. While we're confident in the use cases they solve, the API and implementation may change without a major version bump. (#5040)unstable_cssSideEffectImports future flag. IMPORTANT: Features marked with unstable are … unstable. While we're confident in the use cases they solve, the API and implementation may change without a major version bump. (#4919)unstable_cssModules future flag. IMPORTANT: Features marked with unstable are … unstable. While we're confident in the use cases they solve, the API and implementation may change without a major version bump. (#4852)v2_routeConvention future flag. (#4880)handle in MDX frontmatter (#4865)@remix-run/server-runtime@1.11.0@remix-run/server-runtime@1.10.1create-remix (#4891)@remix-run/server-runtime@1.10.0satisfies keyword) (#4754)parentRouteId lookup in defineConventionalRoutes. (#4800).ts -> .js conversion on Windows by using a relative unix-style path (#4718)@remix-run/server-runtime@1.9.0@remix-run/server-runtime@1.8.2@remix-run/serve@1.8.2future option to the @remix-run/dev/server-build virtual module (#4771)@remix-run/serve@1.8.1@remix-run/server-runtime@1.8.1meta API to handle arrays of tags instead of an object. For details, check out the RFC. (#4610)remix package is deprecated, and all exported modules will be removed in the next major release. For more details,see the release notes for 1.4.0 where these changes were first announced. (#4661)@remix-run/server-runtime@1.8.0@remix-run/serve@1.8.0@remix-run/serve@1.7.6@remix-run/server-runtime@1.7.6@remix-run/serve@1.7.6-pre.0@remix-run/server-runtime@1.7.6-pre.0@remix-run/serve@1.7.5@remix-run/server-runtime@1.7.5@remix-run/server-runtime@1.7.4@remix-run/serve@1.7.4create-remix to use the new examples repository when using --template example/<name> (#4208)moduleResolution to node, node16 or nodenext in tsconfig.json. (#4034)assetsBuildDirectory (#3841)assetsBuildDirectory. (#4130)@remix-run/serve@1.7.3@remix-run/server-runtime@1.7.3@remix-run/server-runtime@1.7.2@remix-run/serve@1.7.2@remix-run/server-runtime@1.7.1@remix-run/serve@1.7.1.gql and .graphql files as plain text (#3923).zip and .avif files as resource URLs (#3985)@remix-run/server-runtime@1.7.0@remix-run/serve@1.7.0.mjs and .cjs file extensions for remix.config (#3675).sql files as text content (#3190)@remix-run/server-runtime@1.6.8@remix-run/serve@1.6.8@remix-run/serve@1.6.7@remix-run/server-runtime@1.6.7.mdx files (#3801)@remix-run/dev/server-build virtual module (#3743)@remix-run/serve@1.6.6@remix-run/server-runtime@1.6.6