如何在npm workspaces中使用Vite自动重建依赖包？

项目结构 #

package.json // 根目录
packages
    @myscope/a
        package.json
        tsconfig.json
    @myscope/b
        package.json
        tsconfig.json
    @myscope/c
        package.json
        tsconfig.json

根目录package.json的工作区配置：

{
    "workspaces": [
        "packages/*"
    ]
}

依赖关系：@myscope/c → @myscope/b → @myscope/a，每个子包都有独立的TS构建命令：

{
    "build": "tsc --build --verbose tsconfig.json"
}

当前在@myscope/c目录执行以下命令启动开发服务：

npx vite serve --mode=development --config vite.config.ts

即使在vite.config.ts中配置了preserveSymlinks: true，修改@myscope/a或@myscope/b的代码时，@myscope/c的Vite服务不会自动重建这些依赖包。

问题1：如何让@myscope/c的Vite命令在@myscope/a和@myscope/b变更时自动重建它们？ #

有两种可行方案：

方案1：用TSC的监听模式配合Vite

利用原有TSC构建命令的--watch参数，在根目录添加监听脚本：

// 根package.json
{
    "scripts": {
        "watch:packages": "tsc --build packages/*/tsconfig.json --watch"
    }
}

启动流程：

1. 先执行npm run watch:packages，让TSC持续监听所有子包的源码变更，自动重新构建JS和类型文件。
2. 再启动@myscope/c的Vite服务。

因为已经配置了preserveSymlinks: true，Vite会读取到子包更新后的构建产物，自动触发热更新。

方案2：配置Vite监听子包源码并联动构建

在@myscope/c的vite.config.ts中添加监听规则，同时结合并行脚本触发子包构建：

// @myscope/c/vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
    resolve: {
        preserveSymlinks: true,
    },
    server: {
        watch: {
            include: [
                'src/**/*', // 监听自身源码
                '../@myscope/a/src/**/*', // 监听@myscope/a的源码
                '../@myscope/b/src/**/*', // 监听@myscope/b的源码
            ]
        }
    }
});

然后在根目录添加并行启动脚本，同时启动子包监听和Vite服务：

// 根package.json
{
    "scripts": {
        "watch:packages": "tsc --build packages/*/tsconfig.json --watch",
        "dev:c": "npm run watch:packages & npm run --prefix packages/@myscope/c dev"
    }
}

执行npm run dev:c即可一次性启动所有必要的服务，子包变更时会自动重建并触发Vite热更新。

问题2：是否需要为@myscope/a和@myscope/b分别配置vite.config.ts？ #

不需要强制配置，分两种情况判断：

• 如果@myscope/a和@myscope/b仅作为依赖库被@myscope/c引用，用原有TSC构建+监听模式完全满足需求，无需额外配置Vite。
• 如果后续需要将这两个包作为独立项目启动（比如需要预览demo），或者想用Vite替代TSC构建（配合vite-plugin-dts生成类型），再给它们单独配置vite.config.ts即可。当前场景下，TSC的方案足够轻量高效。

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