fix(sass): add sassOptions loadPaths to resolve SCSS partials via @/ alias

[ronits2407]

Summary

When a CSS Module uses @use "@/styles/mixins" (the @/ path alias instead of a relative ../../ path), resolve-url-loader strips the file-system working directory from Dart Sass's compilation context. This causes @forward "tables" and all sibling bare imports inside _index.scss to fail:

Error: Can't find stylesheet to import.
  ╷
3 │ @forward "tables";
  │ ^^^^^^^^^^^^^^^^^^
  ╵
  src\styles\mixins\_index.scss 3:1  @use

This was introduced in commit 65541597 where LinkCard.module.scss added @use "@/styles/mixins" as * — the first component file to use the @/ alias for the mixin barrel rather than a relative path.

Root Cause

The loader chain for SCSS modules includes resolve-url-loader → sass-loader. When resolve-url-loader processes a file loaded via a webpack alias (@/styles/mixins), it does not preserve the file-system working directory for Dart Sass. As a result, Dart Sass has no anchor point to resolve @forward "tables" or @forward "./tables" — both fail equally since the directory context is gone.

All other CSS Modules in the project use real relative paths (e.g. @use "../../../../styles/mixins" as *) and are unaffected.

Fix

Added sassOptions to next.config.mjs with explicit load paths:

sassOptions: {
  loadPaths: ["./src/styles", "./src/styles/mixins"],
  includePaths: ["./src/styles", "./src/styles/mixins"],
},

• loadPaths — picked up by Turbopack / modern Dart Sass
• includePaths — picked up by webpack's sass-loader

This gives Dart Sass fallback search paths that survive the stripped context. No SCSS source files were modified.

Verification

• Reproduced the break at commit 65541597 (500 on /internal/dashboard and other routes)
• Confirmed the fix resolves all affected routes locally
• Tested on: Next.js 16.3.0, Dart Sass 1.102.0, Windows (pnpm)

[RsbhThakur]

Tested in local, Looks Good To Me!