v1.17.1

Patch Changes

• Replace esbuild-plugin-polyfill-node with esbuild-plugins-node-modules-polyfill (#6562)
• Lazily generate CSS bundle when import of @remix-run/css-bundle is detected (#6535)
• Updated dependencies:
  • react-router-dom@6.13.0

Changes by Package 🔗

• @remix-run/cloudflare
• @remix-run/css-bundle
• @remix-run/deno
• @remix-run/dev
• @remix-run/eslint-config
• @remix-run/node
• @remix-run/react
• @remix-run/server-runtime
• @remix-run/testing

---

Full Changelog: 1.17.0...1.17.1

v1.17.0

New Features

Suspense Support

Remix 1.17.0 updates to React Router 6.12.0 which wraps internal router state updates in React.startTransition so you can better handle async/suspenseful components within your Remix app.

Error Reporting

If you want better control over your server-side error logging and the ability to report unhandled errors to an external service, you may now export a handleError function from your entry.server.tsx file and take full control over the logging and reporting of server-side errors. (#6495, #6524)

// entry.server.tsx
export function handleError(
  error: unknown,
  { request, params, context }: DataFunctionArgs
): void {
  if (error instanceof Error) {
    sendErrorToBugReportingService(error);
    console.error(formatError(error));
  } else {
    let unknownError = new Error("Unknown Server Error");
    sendErrorToBugReportingService(unknownError);
    console.error(unknownError);
  }
}

future.v2_headers flag

Previously, Remix relied on each leaf route to export it's own headers function to generate headers for document requests. This was a bit tedious and easy to forget to include on new routes, and prohibited child routes from inheriting the headers logic of any ancestor routes. We plan to change this behavior in v2 and have introduced the new behavior behind a future.v2_headers flag. With this new flag enabled, Remix will now return the headers from the deepest headers function found in the matched routes, which allows you to better inherit parent route headers function implementations. If an error boundary is being rendered, the "matched" routes will only contain routes up to and including the error boundary route, but not below. (#6431)

Enhanced Header Management for Errored Document Requests

When rendering a CatchBoundary (or v2 ErrorBoundary) due to a thrown Response from a loader/action, the headers function now has a new errorHeaders parameter that contains any headers from the thrown Response. This allows you to include headers from bubbled responses in your document request response. If the throwing route contains the boundary, then errorHeaders will be the same object as loaderHeaders/actionHeaders for that route. (#6425, #6475)

Dev server updates (future.unstable_dev)

Built-in TLS Support

The new dev server now has built-in TLS support via 2 new CLI options (#6483):

• --tls-key / tlsKey: TLS key
• --tls-cert / tlsCert: TLS Certificate

If both TLS options are set, scheme defaults to https.

Example

Install mkcert and create a local CA:

brew install mkcert
mkcert -install

Then 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 localhost

See 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.pem

or 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 express from "express";
import https from "node:https";
import fs from "node:fs";

let app = express();

// ...code setting up your express app...

let appServer = https.createServer(
  {
    key: fs.readFileSync("key.pem"),
    cert: fs.readFileSync("cert.pem"),
  },
  app
);

appServer.listen(3000, () => {
  console.log("Ready on https://localhost:3000");
});

Known limitations

remix-serve does not yet support TLS. That means this only works for custom app server using the -c flag for now.

Port Management

The new dev server will now reuse the dev server port for the 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).

Other notable changes

• Force Typescript to simplify type produced by Serialize (#6449)
• 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)
• Faster server export removal for routes when unstable_dev is enabled (#6455)
• Better error message when remix-serve is not found (#6477)
• Restore color for app server output (#6485)
• Support sibling pathless layout routes (#4421)
• Fix route ranking bug with pathless layout route next to a sibling index route (#4421)
• Fix dev server crashes caused by ungraceful HDR error handling (#6467)
• Add caching to PostCSS for regular stylesheets (#6505)
• Export HeadersArgs type (#6247)
• Properly handle thrown ErrorResponse instances inside resource routes (#6320)
• Ensure unsanitized server errors are logged on the server during document requests (#6495)
• Retry HDR revalidations in development mode to aid in 3rd party server race conditions (#6287)
• Fix request.clone() instanceof Request returning false (#6512)
• Updated React Router dependencies to the latest versions:
  • react-router-dom@6.12.0
  • @remix-run/router@1.6.3

Changes by Package 🔗

• @remix-run/cloudflare
• @remix-run/css-bundle
• @remix-run/deno
• @remix-run/dev
• @remix-run/eslint-config
• @remix-run/node
• @remix-run/react
• @remix-run/server-runtime
• @remix-run/testing

---

Full Changelog: 1.16.1...1.17.0

v1.16.1

Continuing the work to stabilize features for v2, this release brings improvements to unstable_dev as well as a bunch of bug fixes.

Dev server power-ups 🦾🤖

We've made two huge improvements to 🔥 Hot Data Revalidation 🔥 in 1.16.1! For anyone who needs a refresher on HDR, its like HMR but for your server code. In Remix, that primarily means tracking loader changes.

In 1.16.0, Remix would trigger HDR even if only UI code had changed. Now in 1.16.1, Remix only triggers HDR when loaders have changed. (#6278)

Also, in 1.16.1, Remix now detects code changes that affect your loader anywhere in your app code. You can modify the loader itself, or a function that the loader calls, or hardcoded data. Remix now only triggers HDR to fetch new data from routes with loader changes. For example, if you changed your /products/$id loader, but not your /products loader, Remix only refetches data for /products/$id. (#6299)

If you want to dive deeper into how it works and get a mental model for the new dev server with HDR, check out 🎥 Pedro's talk at Remix Conf.

Dev server bug fixes

Thank you to everyone who's tried unstable_dev ❤️ .
You've given us invaluable feedback that let us identify and fix the following bugs:

• CSS-only changes now correctly trigger HMR (#6374)
• Fixed a regression that caused the old dev server to hang on rebuilds (#6295)
• Rebuilds no longer hang indefinitely for unstable_dev (#6294, #6295)
• Fixed No loader for {.svg,.png, etc...} during HDR (#6396)
• App server port no longer conflicts during rebuilds (#6289)
• Windows: -c/--command option now has access to node_modules/.bin binaries (#6310)
• Windows: App server process in no longer orphaned when dev server exits (#6395)
• Windows: Changes in route files are now detected correctly for HMR/HDR (#6293)

Other notable changes

• css: handle css imports in js files with jsx (#6309)
• css: only process .css.{js,ts} if @vanilla-extract/css is installed (#6345)
• lint: do not require display name in root route (#5450)
• types: Typesafe destructuring of SessionStorage (#6330)
• types: V2_MetaFunction can be undefined (#6231)
• Remix commands no longer modify tsconfig (#6156)
• re-export useMatch from react-router-dom (#5257)
• Updated React Router dependencies to the latest versions:
  • react-router-dom@6.11.2
  • @remix-run/router@1.6.2

Changes by Package 🔗

• @remix-run/cloudflare
• @remix-run/css-bundle
• @remix-run/deno
• @remix-run/dev
• @remix-run/eslint-config
• @remix-run/node
• @remix-run/react
• @remix-run/server-runtime
• @remix-run/testing

---

Full Changelog: 1.16.0...1.16.1

v1.16.0

Remix is full speed ahead preparing for our upcoming v2 release! 1.16.0 stabilizes a handful of CSS features, contains a major overhaul to the internals of the new remix dev server. and fixes a bunch of bugs.

Stabilized CSS Features

CSS Modules/Vanilla Extract/CSS Side-Effect Imports

Version 1.16.0 stabilizes built-in support for CSS Modules, Vanilla Extract and CSS side-effect imports, which were previously only available via future flags (future.unstable_cssModules, future.unstable_vanillaExtract, future.unstable_cssSideEffectImports). In order to use these features, check out our guide to CSS bundling in your project.

PostCSS

Version 1.16.0 stabilizes 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. 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. For more information on PostCSS support, check out the docs.

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.css

After 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.css

You 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"
  }
}

Tailwind

Version 1.16.0 stabilizes 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. For more information on Tailwind support, check out the docs.

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.css

Otherwise, 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"
  }
}

Dev Server Overhaul

🎥 Livestream of Pedro and Kent going over the new dev server

Version 1.16.0 contains a major overhaul to the new dev server, which can be enabled via the future.unstable_dev flag in remix.config.js. The Remix dev server now spins up your app server as a managed subprocess. This keeps your development environment as close to production as possible, and 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:

• force NODE_ENV=development and warn you if it was previously set to something else
• rebuild your app whenever your Remix app code changes
• restart your app server whenever rebuilds succeed
• handle live reload and HMR + Hot Data Revalidation

App server coordination

In 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);
  }
});

Cloudflare

For CF workers and pages, you'll need to use logDevReady instead of broadcastDevReady as the experimental CF runtime won't play nicely with fetch which is how broadcastDevReady is implemented.

For examples, here's a sneak peek 👀 of unstable_dev-enabled templates. Be sure to check out how logDevReady is called in the server.ts files for CF workers and for CF pages.

Options

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,
    },
  },
};

SSL and custom hosts

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 purging

If 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-restart

For 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("all", () => {
  // 1...

v1.15.0

For the last few months we've been working hard on bringing new and improved APIs to Remix. We've introduced several major changes to prepare you for v2 via future flags, and we think v1.15.0 is our last big push to get you ready for the future of Remix.

It's important to note that nothing in your app will break if you do not opt-in to our future flags. 🥳 We are on a mission to provide the smoothest possible upgrade path so you can take it on before a new major release.

Let's get into it 🤓

Preparing for v2 Guide

While these release notes have some information about the APIs, the best way to prepare for v2 is to read the new guide in the docs:

Preparing for v2.

Future Flags

As of v1.15.0, we have deprecated all v1 APIs impacted by v2 future flags. When you run your app in development, we will show a one-time warning for deprecated APIs along with a link that explains how to incrementally migrate to the new APIs before v2 is released.

The v2 future flags include:

• v2_errorBoundary: Removes the CatchBoundary component in favor of handling thrown Response objects in ErrorBoundary directly
• v2_meta: Uses the new function signature for route meta functions and simplifies rendering in <Meta />
• v2_routeConvention: Uses new "flat route" naming conventions
• v2_normalizeFormMethod: useNavigation and useFetcher hooks returning an object with formMethod will uses uppercase method verbs ("GET", "POST", etc.) to align with fetch() behavior

For detailed information on how to use these flags and incrementally upgrade your app, please refer to Preparing for v2 in the Remix docs.

Changes to v2 meta

We have made a few changes to the API for route module meta functions when using the future.v2_meta flag.

• V2_HtmlMetaDescriptor has been renamed to V2_MetaDescriptor
• The meta function's arguments have been simplified
  • parentsData has been removed, as each route's loader data is available on the data property of its respective match object

    // before
    export function meta({ parentsData }) {
      return [{ title: parentsData["routes/parent"].title }];
    }
    // after
    export function meta({ matches }) {
      let parent = matches.find((match) => match.id === "routes/parent");
      return [{ title: parent.data.title }];
    }

  • The route property on route matches has been removed, as relevant match data is attached directly to the match object

    // before
    export function meta({ matches }) {
      let rootModule = matches.find((match) => match.route.id === "root");
    }
    // after
    export function meta({ matches }) {
      let rootModule = matches.find((match) => match.id === "root");
    }

• We have added support for generating <script type='application/ld+json' /> and meta-related <link /> tags to document head via the route meta function

See the v2 meta docs for more information.

useTransition becomes useNavigation

We have deprecated the useTransition hook in favor of the new useNavigation. When we were designing early versions of Remix, the React team shipped their own [at the time] experimental hook called useTransition. To avoid confusion we plan to remove our useTransition hook in v2.

The signature for useNavigation is similar but makes a few key changes to note when upgrading:

import { useTransition } from "@remix-run/react";

function SomeComponent() {
  // before
  let {
    location,
    state,
    submission: { formAction, formData, formMethod },
    type,
  } = useTransition();

  // after
  let {
    // `submission` properties have been flattened
    formAction,
    formData,
    formMethod,
    location,
    state,
  } = useNavigation();
}

Notably, the type property has been removed. It can be derived from the state of a navigation alongside its other properties. See the v2 upgrade guide in our docs for more details.

Deprecated remix.config options

• browserBuildDirectory has been deprecated in favor of assetsBuildDirectory
• serverBuildDirectory has been deprecated in favor of serverBuildPath
• serverBuildTarget has been deprecated in favor of more granular configuration to build for a wider variety of environments

Other notable changes

• The V2_HtmlMetaDescriptor type has been renamed to V2_MetaDescriptor
• We now ensure that stack traces are removed from all server side errors in production
• entry.client and entry.server files are now optional, making it simpler to start a new Remix app without a template or boilerplate
• Bumped React Router dependencies to the latest version. See the release notes for more details.
• Fixed issue to ensure changes to CSS inserted via @remix-run/css-bundle are picked up during HMR
• 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.

Changes by Package 🔗

• @remix-run/cloudflare
• @remix-run/css-bundle
• @remix-run/deno
• @remix-run/dev
• @remix-run/eslint-config
• @remix-run/node
• @remix-run/react
• @remix-run/server-runtime
• @remix-run/testing

---

Full Changelog: 1.14.3...1.15.0

v1.14.3

Fix regression #5631 : dev server keeps running when browser or server builds fail (#5795)

• Changes by Package 🔗
  • @remix-run/dev

---

Full Changelog: 1.14.2...1.14.3

v1.14.2

1.14.2 doesn't contain any functional changes. It just removes a few deprecation warnings that inadvertently shipped in 1.14.1 but were intended for the upcoming 1.15.0 release.

---

Full Changelog: 1.14.1...1.14.2

v1.14.1

Just a bit of housekeeping and a few bug-fixes in this release! Check out the release notes for each package to see what we're up to 👀

• Changes by Package 🔗
  • @remix-run/dev
  • @remix-run/react

New Contributors

• @wizardlyhel made their first contribution in #5603
• @buzinas made their first contribution in #5576
• @TomerAberbach made their first contribution in #5430

---

Full Changelog: 1.14.0...1.14.1

v1.14.0

New Development Server with HMR 🔥

You asked for it, and now we're stoked to deliver. We've got a brand new dev server that we think will dramatically improve the experience of running your Remix apps in development.

The new dev environment includes long-anticipated Hot Module Replacement (HMR) via React Refresh, as well as something we're calling Hot Data Revalidation (HDR)

HMR allows you to make changes to your UI or style code and see them reflected in your browser without having to refresh the page. This is different from our existing <LiveReload> component, as HMR will not reset client-side state between updates. This is particularly useful for highly-interactive apps where resetting state is disruptive and slows down the development process.

Now for HDR. Think of it as HMR for data loaders. With HDR you can make changes to your server code and see those updates reflected in your UI immediately without resetting client-side state, just like HMR.

This is an early release available under the unstable_dev future flag, but we're excited to get it into your hands, gather feedback and provide a first-class developer experience for apps at any scale. As of now, there are some known limitations to be aware of:

• We don't yet expose an API for import.meta.hot
• All route loaders are invalidated when changes are detected on the server
• Loader changes do not account for changes in imported dependencies
• It's doesn't work automatically with the Remix App Server, you'll want to bring in @remix-run/express for your server. This will not be a limitation when the unstable flag is removed.

Using HMR/HDR

First, you need to enable the new dev server in your remix.config.js:

module.exports = {
  // ...
  future: {
    unstable_dev: true,
  },
};

The new dev server and HMR/HDR requires two processes, one for your build and one for your app. You can run these in separate tabs or you can use something like npm-run-all to run them in parallel via a package.json script. We are also using nodemon to auto-restart our server on build changes. It's important to note that we're setting NODE_ENV=development here which is required to enable HMR/HDR.

Using the Remix App Server:

// package.json scripts
"dev": "run-p dev:*",
"dev:build": "cross-env NODE_ENV=development remix dev",
"dev:serve": "cross-env NODE_ENV=development nodemon --watch build node_modules/.bin/remix-serve build",

Using an Express Server:

// package.json scripts
"dev": "run-p dev:*",
"dev:build": "cross-env NODE_ENV=development remix dev",
"dev:serve": "cross-env NODE_ENV=development nodemon --watch build server.js",

Other notable changes

• entry.server and entry.client files are now optional. If excluded, Remix will use reasonable defaults at build-time. If you need customization for these files, you can run npx remix reveal and it will generate them for you.
• For users using the v2_routeConvention flag, route conflicts will no longer throw errors. Instead, you'll see a helpful warning that points to the conflict, and the first match we find will be used.

  ⚠️ 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.tsx
  

Miscellaneous

• Updated to latest React Router versions. See the release notes for more details.
  • react-router-dom@6.8.2
  • @remix-run/router@1.3.3
• Changes by Package 🔗
  • @remix-run/cloudflare
  • @remix-run/cloudflare-workers
  • @remix-run/dev
  • @remix-run/react
  • @remix-run/serve
  • @remix-run/server-runtime
  • @remix-run/testing

v1.13.0

This Valentine's Day, get that special someone in your life what they really want: more styling options—out of the box—in Remix 🥰

Built-in PostCSS support

Remix can now process your existing CSS imports with PostCSS. A lot of folks have been doing this for quite some time, but in Remix this previously required you to run any CSS transformations as a separate process, and imports would need to reference the output rather than the source.

No longer! Now you can import references to the CSS files you actually write and Remix will take care of the rest. This is opt-in under the future.unstable_postcss flag in remix.config. From there, all you need is PostCSS configured in your app.

// remix.config.js
module.exports = {
  future: {
    unstable_postcss: true,
  },
};

// postcss.config.js
module.exports = {
  plugins: [/* your plugins here! */],
  presets: [/* your presets here! */],
};

// app/routes/root.jsx
// huzzah, the stylez are transformed before your very eyes!
import stylesheet from "./root.css";

export const links: LinksFunction = () => [
  { rel: "stylesheet", href: stylesheet },
];

Built-in Tailwind support

Valentine's Day is all about expressing how you feel, and what else evokes stronger feelings than Tailwind? 🙈

For all of our fellow lovers, you can now get your Tailwind styles generated without running a separate process. As with PostCSS, you'll need to opt-in (for now) with the future.unstable_tailwind flag.

// remix.config.js
module.exports = {
  future: {
    unstable_tailwind: true,
  },
};

If you haven't already, install Tailwind and initialize a config file.

npm install -D tailwindcss
npx tailwindcss init

Then you can create a stylesheet and use Tailwind directives wherever you'd like,

/* app/tailwind.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

Now you can import your stylesheet and link to it in your route, and you're good to go!

// app/routes/root.jsx
// huzzah, the stylez are transformed before your very eyes!
import stylesheet from "~/tailwind.css";

export const links: LinksFunction = () => [
  { rel: "stylesheet", href: stylesheet },
];

Fine-tuning your server build

We are deprecating serverBuildTarget in remix.config. Instead, you can target your server build with our more granular config options, granting you much more flexibility in where and how you ship.

Moving forward, you have a number of options that will help you configure your server bundle to fit your needs:

• publicPath
• serverBuildPath
• serverConditions
• serverDependenciesToBundle
• serverMainFields
• serverMinify
• serverModuleFormat
• serverPlatform

Fixes and enhancements for v2_routeConventions

We recently rolled out early experimental support for new route conventions to prepare you for Remix v2. We've fixed a few bugs and made a number of improvements for our eager early adopters.

One such enhancement we wanted to call out is how we can disambiguate "index routes" from "index modules". Turns out many people don't know about "index modules" or "folder imports" in node.js that our "flat route folders" depended on. Instead of trying to explain the difference, we went with a new convention: route.tsx.

When you want to split your route module out into multiple co-located modules, you can turn it into a folder and put the route at folder/route.tsx (or folder/route.jsx) and the rest of the modules in the folder will be ignored.

Consider this route:

routes/contact.tsx

When you want to split it up, you can make it a folder with a route.tsx file inside:

routes/contact/route.tsx <- this is the route module
routes/contact/form.tsx <- this is just a module, ignored by the route convention

For those of you who do know the difference between an index route and a node index module, index.tsx will continue to work inside folders, but we'd rather you use route.tsx

For more information, check out the docs for the v2 file convention.

Please note that this only applies if you have opted in to the new route conventions in future.v2_routeConventions. Current v1 behavior for file-system routing has not changed.