How to Fix: @import on CSS file not working when i use Turbopack

Updated June 8, 2026 4 min read

Aldawsari

4 min read

Turbopack can fail on CSS @import statements that pull package files from node_modules, even when the same setup works with Webpack. In this case, importing Radix CSS through @import inside a stylesheet is the trigger: Turbopack’s CSS pipeline does not fully support that resolution path the same way the classic bundler does, so the stylesheet is skipped or not resolved correctly.

Table of Contents

Understanding the Root Cause
Step-by-Step Solution
Common Edge Cases
FAQ

Understanding the Root Cause

The bug happens because Turbopack currently handles some CSS dependency resolution paths differently from Webpack, especially when a CSS file uses @import to reference package assets such as Radix theme styles.

A pattern like this is often the problem:

@import "@radix-ui/themes/styles.css";

Under Webpack, this commonly resolves through the package graph without issue. Under Turbopack, that same import may not be processed as expected when it appears inside another CSS file. The result is usually one of these symptoms:

The imported styles never appear in the browser.
The dev server shows a CSS resolution error.
The app renders, but all package-provided styles are missing.

Technically, the issue is not that Radix CSS is invalid. The problem is the interaction between Turbopack’s CSS loader behavior and package-level stylesheet imports performed via @import. This is why moving the import into JavaScript or TypeScript usually fixes it immediately: the framework resolves the stylesheet through the application entry graph rather than through nested CSS import handling.

Step-by-Step Solution

The most reliable fix is to stop importing the package CSS through @import inside a CSS file and instead import it directly from your app entry, usually app/layout.tsx, app/layout.jsx, or pages/_app.tsx.

1. Remove the CSS `@import`

If your global stylesheet looks like this:

@import "@radix-ui/themes/styles.css";

:root {
  --app-font: Inter, sans-serif;
}

change it to:

:root {
  --app-font: Inter, sans-serif;
}

2. Import the package stylesheet in your app entry

For the App Router, update app/layout.tsx:

import "@radix-ui/themes/styles.css";
import "./globals.css";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

For the Pages Router, update pages/_app.tsx:

import "@radix-ui/themes/styles.css";
import "../styles/globals.css";

export default function App({ Component, pageProps }) {
  return <Component {...pageProps} />;
}

3. Restart the dev server

After changing stylesheet imports, restart the server so Turbopack rebuilds the dependency graph cleanly.

npm run dev

or:

pnpm dev

4. Verify that Turbopack is the actual variable

If you want to confirm the diagnosis, run the app without Turbopack and compare behavior. If it works there but fails with Turbopack, that strongly confirms a bundler-specific CSS import limitation.

next dev

and compare with:

next dev --turbo

5. Temporary fallback if you must keep the old structure

If your team depends on CSS-level @import organization, the short-term fallback is to disable Turbopack for development until the issue is fixed upstream.

next dev

You should also monitor the relevant issue tracker in the Next.js GitHub issues for updates, because this is likely to improve as Turbopack’s CSS support matures.

Recommended final structure

app/
  layout.tsx
  globals.css

// app/layout.tsx
import "@radix-ui/themes/styles.css";
import "./globals.css";

/* app/globals.css */
:root {
  --app-font: Inter, sans-serif;
}

body {
  margin: 0;
}

Common Edge Cases

Import order problems: If you import your local CSS before the package CSS, your overrides may behave differently. In most cases, import third-party base styles first, then your own stylesheet.
Mixing App Router and Pages Router patterns: Import global CSS only from the correct framework entry point. Putting global styles in arbitrary components can cause build errors.
PostCSS confusion: If you are also using Tailwind CSS or custom PostCSS plugins, it can look like a PostCSS failure when the real problem is Turbopack’s package CSS resolution.
Incorrect package path: Verify the exact CSS file exported by the package. A wrong subpath can produce the same symptom even outside Turbopack.
Hot reload cache issues: Turbopack may preserve stale module state during development. If the fix does not appear immediately, stop the dev server and start it again.
Using CSS Modules for globals: Package theme files should not be pulled into .module.css files when they are intended to be global.

FAQ

Why does `@import` work without Turbopack but fail with Turbopack?

Because Webpack and Turbopack do not yet behave identically for every CSS resolution case. Nested CSS imports from package paths are one area where Turbopack can still differ.

Can I still use Radix Themes with Turbopack?

Yes. The practical fix is to import the Radix stylesheet directly in layout.tsx or _app.tsx instead of via CSS @import.

Is this a Radix bug or a Next.js/Turbopack bug?

It is generally a Turbopack CSS handling limitation, not a Radix-specific problem. Radix just happens to expose the issue because its styles are often imported from package CSS files.

If your goal is stability today, the safest rule is simple: for package-level global CSS, prefer JavaScript or TypeScript imports at the app entry point instead of CSS @import when using Turbopack.