Skip to content

fix(sass): include node_modules in Dart Sass loadPaths to fix Windows @import resolution#93842

Open
creazyfrog wants to merge 1 commit into
vercel:canaryfrom
creazyfrog:fix/sass-windows-node-modules-load-paths
Open

fix(sass): include node_modules in Dart Sass loadPaths to fix Windows @import resolution#93842
creazyfrog wants to merge 1 commit into
vercel:canaryfrom
creazyfrog:fix/sass-windows-node-modules-load-paths

Conversation

@creazyfrog

Copy link
Copy Markdown

Summary

Fixes #93583.

On Windows (native, no WSL), sass-loader with the modern Dart Sass API fails to resolve relative @import statements inside node_modules packages. For example, @primer/css/color-modes/index.scss does @import './themes/light.scss', and the build fails with:

Error: Can't find stylesheet to import.
  @import './themes/light.scss'
  node_modules\@primer\css\color-modes\index.scss

Root cause

When the sass-loader webpack importer (webpackImporter: true, the default) can't resolve the path on Windows due to backslash/forward-slash path separator differences, it returns null. Dart Sass then falls back to its built-in resolver, but that resolver only searches the file's own directory and user-specified loadPaths. Since node_modules is not in loadPaths by default, the relative import inside the package fails.

Fix

In packages/next/src/build/webpack/config/blocks/css/index.ts, prepend <rootDirectory>/node_modules to the loadPaths option passed to sass-loader. This ensures Dart Sass can always resolve package imports natively, regardless of whether the webpack importer succeeds.

User-specified sassOptions.loadPaths values are preserved and appended after the default, so there is no breaking change.

- sassOptions,
+ sassOptions: {
+   ...restSassOptions,
+   loadPaths: [
+     path.join(ctx.rootDirectory, 'node_modules'),
+     ...(userLoadPaths ?? []),
+   ],
+ },

Why this is safe

  • Adds a fallback resolution path; does not change how existing working imports resolve
  • Dart Sass's own documentation recommends loadPaths for resolving packages from node_modules
  • User-provided loadPaths values take precedence (appended after the default) and continue to work unchanged
  • No effect on Turbopack (Turbopack has its own Sass pipeline)

Test plan

  • On Windows 10/11 (native Node.js, no WSL): clone github/docs, run npm install && npm run dev — build should succeed without SCSS import errors
  • On Linux/macOS: verify existing SCSS imports still work correctly (no regression)
  • Projects with custom sassOptions.loadPaths values should still work

🤖 Generated with Claude Code

…import resolution

On Windows, the sass-loader webpack importer loses path context when
resolving relative @import statements inside node_modules packages
(e.g. @import './themes/light.scss' inside @primer/css). The importer
returns null, and Dart Sass's built-in resolver also fails because
node_modules is not in its loadPaths.

Fix: prepend <rootDirectory>/node_modules to the Dart Sass loadPaths
option so the native resolver can always find package files. User-
specified loadPaths are preserved and appended after the default.

Fixes vercel#93583.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug] Windows: sass-loader fails to resolve SCSS imports from node_modules in webpack mode (not Turbopack)

2 participants