Vite+Yarn Workspace Monorepo中SCSS依赖@carbon/styles解析失败咨询

这是预期行为吗？ #

是的，这属于预期行为，核心原因是SCSS 的模块解析逻辑和 JavaScript 完全独立：

• JavaScript/TypeScript 模块遵循 Node.js 的模块解析规则，会从当前子包的 node_modules 开始，逐级向上遍历父目录（直到 monorepo 根目录）的 node_modules，因此能找到被提升的公共依赖。
• 而 SCSS 的 @use/@import 由 Sass 自身解析器处理，默认仅查找：
  • 当前 SCSS 文件的相对路径
  • Sass 配置中 includePaths 指定的目录
    它不会自动向上遍历父目录的 node_modules，所以当 @carbon/styles 被提升到 monorepo 根目录的 node_modules 时，子包的 SCSS 无法定位到该依赖。

更全局的解决方案（让 SCSS 解析与 JS 逻辑对齐） #

1. 在 monorepo 根目录统一配置 Vite 的 Sass 包含路径 #

在根目录的 vite.config.ts 中添加全局 Sass 预处理配置，将根目录的 node_modules 加入 includePaths，所有子包的 SCSS 解析都会自动遍历根目录依赖，和 JS 的查找逻辑保持一致：

import { defineConfig } from 'vite';
import path from 'path';

export default defineConfig({
  css: {
    preprocessorOptions: {
      scss: {
        includePaths: [path.resolve(__dirname, 'node_modules')],
      },
    },
  },
});

若子包有单独的 Vite 配置，确保通过 extends 字段或导入根配置的方式继承该全局设置。

2. 调整包管理器的依赖提升策略（你提到的 nmHoistingLimits: workspaces） #

这也是一种全局方案，设置后 Yarn 会将公共依赖以软链或副本形式安装到每个子包的 node_modules 中，SCSS 从当前子包的 node_modules 即可找到 @carbon/styles，和 JS 的查找路径完全匹配。缺点是会生成额外的软链/副本，占用少量磁盘空间，但无需修改构建配置。

3. 全局配置 Sass 的包含路径（备选） #

若项目不依赖 Vite 专属配置，可在 monorepo 根目录创建 .sassrc 或 sass.config.js 文件，全局指定 includePaths：

// sass.config.js
const path = require('path');

module.exports = {
  includePaths: [path.resolve(__dirname, 'node_modules')],
};

注意：Vite 会优先读取自身 css.preprocessorOptions 中的配置，因此更推荐第一种方案。

内容的提问来源于stack exchange，提问作者nstuyvesant