Next.js Windows SCSS Imports from node_modules Failing: Fix

Problem

If your Next.js app builds fine on macOS or Linux but starts throwing SCSS resolution errors on Windows, the recent open bug in the Next.js repo is worth paying attention to.

On May 7, 2026, the Next.js issue tracker picked up a very specific regression: in webpack mode on Windows, sass-loader can fail to resolve SCSS imports from node_modules, while the same setup works in Turbopack. That is the kind of bug that quietly wastes a day because teams first assume they broke their design system imports, not the toolchain.

I care about this one because it hits a real production workflow:

• developers building locally on Windows
• CI runners that do not match the main team platform
• packages that expose SCSS tokens or partials instead of compiled CSS

That combination still shows up a lot in client projects, especially when a design system package is shared across several apps.

If you are already dealing with package-resolution friction in Next.js, my earlier post on Next.js Turbopack Linked Package Reload Fix is a useful companion. It is a different bug, but it lives in the same category: framework tooling behaving differently once packages leave the simplest path.

Why It Happens

The useful part of the recent issue is the scope. This is not a generic "SCSS is broken in Next.js" report.

The issue is specific to:

• Windows
• webpack mode
• SCSS imports coming from node_modules
• setups that do not reproduce the same way in Turbopack

That tells you where not to waste time.

I would not start by blaming your component code. I would start by looking at how the import is being resolved.

There are a few reasons Windows tends to make this uglier:

1. Path normalization is stricter than people think

Mixed separators, deep package-relative imports, and assumptions copied from Unix machines can all surface differently on Windows.

2. SCSS packages often expose internal partials, not a stable public entrypoint

A lot of teams import styles like this:

@use "@acme/ui/src/styles/tokens" as *;
@use "@acme/ui/src/styles/mixins" as *;

That works until the loader, the package boundary, or the path handling changes underneath you.

3. Webpack and Turbopack are not identical resolution environments

That matters in this bug because the same project can look healthy in Turbopack and fail in webpack mode. If your team flips between the two without realizing it, the issue looks random when it is actually environment-specific.

The Fix

Until the upstream bug is closed, I would use the least fragile workaround available instead of trying to outsmart the loader with clever import chains.

My order of preference is:

1. Stop importing deep SCSS internals from packages

If a package gives you a public stylesheet entrypoint, use that first. Treat src/styles/... imports inside a dependency as unstable.

2. Make the loader path explicit

Next.js exposes sassOptions, and for this kind of Windows-specific path issue I prefer being explicit about where Sass should resolve from:

import path from 'node:path'
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  sassOptions: {
    includePaths: [
      path.join(process.cwd(), 'styles'),
      path.join(process.cwd(), 'node_modules'),
    ],
  },
}

export default nextConfig

Then keep the import shape as boring as possible:

@use "bootstrap/scss/functions";
@use "bootstrap/scss/variables";
@use "bootstrap/scss/mixins";

That does not magically fix every broken package, but it removes one layer of guesswork from resolution.

3. Prefer Turbopack if your project is already stable there

The open issue is specifically about webpack mode, not Turbopack. If your repo is already running cleanly with Turbopack, I would not force webpack just because an old script still exists.

4. Vendor the tiny SCSS surface you actually need

If a dependency only exposes a couple of tokens or mixins and the Windows path keeps breaking, I would rather copy the stable subset into the app than keep importing deep package internals forever.

That is not elegant, but it is often the fastest way to unblock a release.

What I Check Before Calling It Fixed

I run the same import path through three environments:

• local Windows machine
• local or CI webpack build
• local Turbopack dev flow

If one path works and one fails, I keep the diagnosis toolchain-focused. I do not start refactoring component styles yet.

I also check whether the package should really be exposing SCSS to consumers at all. In a lot of codebases, compiled CSS or CSS variables are the better interface. Shipping raw Sass internals through a package is flexible, but it also makes every consuming app part of your build setup.

The best references here are the recent open Next.js issue on Windows SCSS resolution and the official sassOptions docs. The issue matters because it narrows the scope. The docs matter because they show the sanctioned place to put the workaround.

The Practical Takeaway

When SCSS imports from node_modules suddenly fail only on Windows, assume a loader-resolution problem first.

That mindset saves time. You stop chasing phantom syntax errors in your stylesheets and start checking the part that actually changed: the environment boundary between Next.js, webpack, Sass, and the package layout.

CTA

If your Next.js build keeps breaking across environments or package boundaries, see my services. I help teams fix framework and frontend tooling issues without turning the repo into a pile of one-off workarounds.