Link to the code that reproduces this issue

https://github.com/Xanaado/nextjs-turbopack-sass-sourcemap-bug

To Reproduce

1. Create a Next.js 16 project with Turbopack enabled
2. Install SASS: npm install sass
3. Create the following SCSS structure:

styles/
├── index.scss
└── components/
    ├── empty-file.scss
    ├── header.scss
    ├── button-primary.scss
    ├── button-secondary.scss
    ├── button-success.scss
    └── button-danger.scss

1. In index.scss, import the scss file using @use or @import
2. Add styles to each component file (e.g., in button-primary.scss):

  .button-primary {
    padding: 12px 24px;
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
  }

1. In empty-file.scss, add only a placeholder class:

  .empty-placeholder {
    display: none;
  }

1. Import the main stylesheet in your layout and use the classes in your page
2. Start the development server with next dev
3. Open the browser DevTools and inspect an element styled by rules from button-xx.scss
4. sourcemap will always show index.scss

Screenshots demonstrating the bug:

##SCSS File Structure

The reproduction uses 6 separate SCSS files with @use directives:

Empty File Content

empty-file.scss is the first @use import and contains NO button or header styles - only a placeholder class:

The Bug in DevTools

When inspecting .button-primary styles in DevTools, the source map incorrectly points to empty-file.scss:5 instead of button-primary.scss:2:

This demonstrates that Turbopack always uses the first @use import for all source map references, regardless of which file actually contains the styles

Current vs. Expected behavior

Expected Behavior

Source maps should point to the actual file containing the styles:

• .button-primary styles → components/button-primary.scss
• .button-secondary styles → components/button-secondary.scss
• .header styles → components/header.scss

Actual Behavior

All source maps point to empty-file.scss (the first @use import), regardless of which file actually contains the styles:

• .button-primary styles → components/empty-file.scss
• .button-secondary styles → components/empty-file.scss
• .header styles → components/empty-file.scss

This is the standard behavior with Webpack and with other bundlers that properly handle SASS module system source maps. (Although in webpack you need to enable it in the config)

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32691
  Available CPU cores: 16
Binaries:
  Node: 24.12.0
  npm: 11.6.2
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 16.1.1-canary.18 // Latest available version is detected (16.1.1-canary.18).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Turbopack, CSS

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

Investigation findings Prior to version 16.1.1-canary.14, the names field of CSS source maps was not being extracted at all. This was addressed in [PR #87911] which properly populates the names field of source maps. However, even after this PR was merged in 16.1.1-canary.14, CSS source maps still point to the incorrect file. After debugging the Turbopack code that handles CSS source maps, I discovered that it always sets the first index when mapping CSS sources, which causes all styles to be attributed to the entry point file (index.scss) instead of their actual source files. Proposed solution I've created a PR [#88225] that:

1. Introduces a new configurable next.config.js option to enable proper CSS source maps
2. Fixes the Turbopack CSS source map handler to correctly map to the actual source file instead of always using the first index
3. Only works with Next.js versions 16.1.1-canary.14 and later (since it requires the names field to be populated)

This issue appears specifically when using:

• Turbopack in development mode
• SASS with the modern module system (@use and @forward and @import)
• Any version of next using turbopack

The line numbers in the source maps are accurate, indicating that Turbopack is correctly tracking the original line positions. However, the filename resolution is broken due to the Turbopack CSS handler always using the first index. This significantly impacts developer experience as it's difficult to locate and edit the correct SCSS files when debugging styles.