VSCode本身不打包脚本依赖，需靠npm或vsce：插件场景用vsce package且依赖须列在dependencies；脚本工具场景共享package.json+package-lock.json，接收方执行npm ci还原依赖。
VSCode 本身不打包脚本依赖，得靠 npm + vsce
VSCode 不是运行时环境，它不负责安装、打包或分发你代码里 require('lodash') 或 import axios from 'axios' 所依赖的第三方包。所谓“共享包含依赖项的完整脚本包”，本质是把一个可独立运行的 VSCode 插件（.vsix）或一个带 node_modules 的脚本工程传给他人——前者走插件发布流程，后者走项目交付流程。
常见错误现象：
- 直接把
src/目录压缩发给同事，对方npm start报Cannot find module 'chokidar' - 用
vsce package打包后，别人安装 .vsix 却提示“扩展激活失败”，日志里是ReferenceError: require is not defined - 以为复制整个
node_modules就完事，结果 Git 忽略了它，或者不同平台（Windows/macOS）下二进制依赖无法复用
实操建议：
- 插件场景：确保所有运行时依赖都列在
package.json的dependencies字段，而非devDependencies；执行npm install后再跑vsce package，生成的 .vsix 已含所需模块 - 脚本工具场景（非插件）：不要传
node_modules，而是传package.json+package-lock.json；接收方只需npm ci（不是npm install），就能还原完全一致的依赖树 - 若脚本需离线运行且不能联网，可用
npm pack打成 tarball，或用npx pkg编译为单文件可执行程序（注意：pkg不支持所有 native 模块）
vsce package 为什么没打进你的依赖？检查这三处
vsce package 只打包 node_modules 中被实际引用的模块，而且只认 dependencies —— 它不会管你代码里写了 require('fs-extra') 却没写进 package.json。
容易踩的坑：
-
package.json里漏写"dependencies": { "fs-extra": "^11.2.0" }，只写了devDependencies→ 打包后缺失 - 用了
import * as yaml from 'js-yaml'，但js-yaml是optionalDependencies→vsce默认跳过，需加--no-yarn并确认npm ls js-yaml能查到 - 插件入口文件（如
extension.js）里动态require(moduleName)，vsce静态分析不到 → 必须显式require('module-name')一次，或改用dependencies声明 +import()动态导入
验证方式：解压生成的 .vsix（它就是 zip），检查 extension/node_modules/ 下是否存在对应包目录；或运行 vsce ls 查看打包内容清单。
共享脚本包时，Python 和 Node.js 处理逻辑完全不同
别混用 Python 的思维去理解 Node.js 的依赖打包。VSCode 对这两类脚本的“共享”没有统一机制，各自路径清晰：
- Python 脚本：共享的是
.py文件 +requirements.txt（推荐用pipreqs生成）+ 显式说明解释器路径（如./venv/bin/python）；接收方必须自己python -m pip install -r requirements.txt - Node.js 脚本：共享的是
package.json+package-lock.json+src/；接收方运行npm ci，不是npm install—— 后者可能升级 minor 版本，破坏兼容性 - 混合项目（如 Python 调 Node.js 子进程）：必须分开管理；Node.js 部分仍走
npm ci，Python 部分走pip install -r requirements.txt，不能指望一个命令解决全部
性能影响：用 npm ci 比 npm install 快 2–5 倍，因为它跳过解析 package.json、直接按 package-lock.json 安装，且校验完整性哈希。这是离线或 CI 场景下的事实标准。
离线共享时，.vsix 不等于“开箱即用”
哪怕你用 vsce package 打出 .vsix，对方离线安装后仍可能失败——因为 VSCode 插件的依赖链里，有些包（如语言服务器）默认是首次激活时才下载远程二进制。
关键限制：
-
extensionDependencies声明的其他插件（如ms-python.python）不会随 .vsix 一起安装，必须手动提醒用户提前装好 - 某些插件在
activate()里调用download或fetch加载 WASM/模型文件，离线环境下会卡住或报NetworkError - Windows 上用
node-gyp编译的原生模块（如fsevents）在 macOS 打包的 .vsix 里无法运行，跨平台必须分别构建
所以真正的离线共享，不是“一份 .vsix 到手就完”，而是：
- 提前在目标环境（同 OS + 同 VSCode 版本）上测试安装与激活流程
- 把所有远程资源（如 LSP server binary、JSON Schema 缓存）预下载并硬编码为本地路径，或打包进 .vsix 的
resources/目录 - 提供明确的 README：列出必须手动安装的 extension ID、最低 VSCode 版本、是否需要管理员权限等
最常被忽略的一点：VSCode 插件的 engines.vscode 字段声明的是最低兼容版本，但如果你用了 vscode.window.withProgress 这类新 API，而对方还在用 1.70 版本，就会静默失败——没有报错，只是功能不出现。
