我之前开发VSCode扩展的复合项目时，也踩过几乎一模一样的路径别名坑！咱们一步步来排查修复，先搞定编译时的TypeScript错误，再处理运行时的Node.js模块解析问题：

一、先解决编译时的核心问题 #

1. 修正根目录tsconfig的include配置 #

你根目录tsconfig.json里的include设成了["*.ts"]，这只会匹配根目录下的TS文件，但你的代码全在client/server/shared子目录里，而且复合项目主要靠references关联子项目，这个配置反而可能让TypeScript服务混淆。建议改成空数组：

// 根目录tsconfig.json
"include": []

2. 确保Shared项目已正确编译（复合项目关键） #

因为client和server都通过references依赖shared，TypeScript需要读取shared编译后的类型定义文件（.d.ts）才能识别别名。在根目录执行下面的命令，一次性编译所有关联项目：

tsc -b

执行完后去shared/out目录看看，有没有生成对应的.d.ts和.js文件——这是复合项目依赖识别的核心前提。

3. 让VSCode的TypeScript服务正确识别工作区配置 #

有时候VSCode默认用的是内置TypeScript版本，它可能不会自动读取你的复合项目配置。解决方法很简单：

• 打开client/src/extension.ts文件
• 点击VSCode右下角的TypeScript版本号（比如5.2.2）
• 选择「Use Workspace Version」，切换成你项目node_modules里安装的TypeScript版本

二、处理运行时的模块解析问题（编译过了但运行时报错） #

TypeScript的paths别名只是编译时配置，Node.js运行时本身不认识这个别名，得额外处理：

1. 安装tsconfig-paths依赖 #

在根目录执行：

npm install tsconfig-paths --save-dev

2. 修改启动脚本，加入路径解析钩子 #

比如你的client启动脚本原来可能是这样的：

"scripts": {
  "start": "node ./out/extension.js"
}

改成用tsconfig-paths/register来加载路径映射：

"scripts": {
  "start": "node -r tsconfig-paths/register ./out/extension.js"
}

同时注意：运行时client的paths要指向shared的编译输出目录，所以调整client/tsconfig.json里的配置：

// client/tsconfig.json
"paths": {
  "@shared/*": ["shared/out/*"]
}

三、最后检查几个细节 #

• 确认shared/src/storage-data-manager.ts文件确实存在，而且文件名大小写和你的import语句完全一致（你开了forceConsistentCasingInFileNames，大小写不匹配会直接报错）
• 检查shared/tsconfig.json里的outDir是out，编译后文件都会输出到shared/out，这个路径要和client/server的paths配置对应上
• 如果你用vscode-test调试扩展，记得在.vscode/launch.json的runtimeArgs里也加入钩子：

"runtimeArgs": [
  "-r", "tsconfig-paths/register"
]

按这个流程走下来，应该就能解决找不到@shared模块的问题了！如果还是有问题，可以试试删除所有out目录和.tsbuildinfo文件，重新执行tsc -b干净编译一次，很多时候缓存会导致奇怪的问题。