Turbopack sometimes strips scss imports

[AlessioGr]

Link to the code that reproduces this issue

https://github.com/payloadcms/payload/tree/turbo-bug-reproduction

To Reproduce

1. pnpm i
2. pnpm next dev, then open http://localhost:3000
3. You will notice scss import errors - this is good!
4. pnpm next dev --turbo, then open http://localhost:3000
5. No scss import errors. This is a problem

Current vs. Expected behavior

I encountered an issue in Turbopack where some components do not import their SCSS files, despite having an import './index.scss' statement.

To verify, I tested importing a non-existent SCSS file: Webpack correctly throws an error, but Turbopack does not.

This suggests that Turbopack’s AST parser may be stripping out SCSS imports under specific conditions. In particular, the problem arises when importing a component that imports another component (which imports SCSS) from a monorepo package whose package.json has "sideEffects": false.

If I import the component directly from the app folder, skipping the monorepo package that has "sideEffects": false, it works.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:23 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6031
  Available memory (MB): 65536
  Available CPU cores: 16
Binaries:
  Node: 22.13.1
  npm: 10.9.2
  Yarn: 1.22.22
  pnpm: 9.15.5
Relevant Packages:
  next: 15.2.0-canary.74 // Latest available version is detected (15.2.0-canary.74).
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.7.3
Next.js Config:
  output: N/A

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

Turbopack

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

next dev (local)

Additional context

No response

[timneutkens]

Did some digging into this to reduce the reproduction. Seems there's 2 bugs:

• Non-existent .scss files don't error
• sideEffects: existing causes the Sass to be ignored

I've narrowed down the second issue in this sandbox: https://codesandbox.io/p/github/payloadcms/payload/csb-cfjgm2/draft/friendly-swirles?file=%2Fpackages%2Fui%2Fpackage.json%3A4%2C41

On that sandbox removing sideEffects makes the background red (correct).

Regardless the package should have "sideEffects": ["*.scss", "*.css", "*.sass"], since there is code with side effects (CSS / Sass)

[AlessioGr]

Regardless the package should have "sideEffects": [".scss", ".css", "*.sass"], since there is code with side effects (CSS / Sass)

This makes sense! I tried that, but it currently behaves the same as setting "sideEffects": false.

Seems there's 2 bugs:

I was thinking that it's essentially just one bug - just 2 different ways to reproduce it. Incorrectly stripping the scss would both cause incorrect scss imports not to error, and correct scss imports to be ignored.

sideEffects: existing causes the Sass to be ignored

To clarify, this only happens if those two other conditions are also met:

• Component that imports scss is not directly exported. If you skip the intermediary Parent component and export the Child directly, it works
• That component needs to have another, unrelated export statement, that exports something from a different file

Thus I would say there is a second bug: the expected behavior of "sideEffects": false seems to be broken, since it doesn't always skip importing those scss files (given that the expected behavior of it is to treeshake those imports).

In this case this would be a bug in webpack as well, since webpack has never stripped those scss imports

[mischnic]

The missing build error is not specific to (S)CSS: the same thing happens when doing import './incorrect.js'.

It appears that if a module marked as sideEffects: false has a bare import without any bindings, then that import is just completely ignored (regardless of whether the target module has sideEffects).