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.