npm脚本不显示需先确认项目启用node.js支持：右键根目录→add framework support→勾选node.js，并确保package.json位于项目最外层；若用pnpm/yarn，须在设置中指定对应包管理器路径。
npm脚本在WebStorm里不显示？先检查package.json是否被识别为项目根
WebStorm不会自动把任意文件夹当Node.js项目处理。如果npm工具窗口空白或脚本列表为空，大概率是项目未正确启用Node.js支持。
确认方式：右键项目根目录 → “Add Framework Support…” → 勾选 Node.js。这会触发WebStorm扫描package.json并加载scripts字段。
- 必须确保
package.json位于项目最外层（即File → Project Structure → Project Settings → Project → Project SDK指向的根路径下） - 如果用了
pnpm或yarn，需在Settings → Languages & Frameworks → Node.js and NPM中指定对应包管理器路径，否则脚本可能无法执行或参数解析异常 - 修改
package.json后，WebStorm不会实时刷新脚本列表；手动点击NPM工具窗口右上角的Reload project图标（↻）才能同步
运行带参数的npm脚本时，npm run dev -- --port=4001怎么在UI里填？
WebStorm的“Run npm script”对话框不支持直接输入双横线--分隔符。它把所有额外参数当作脚本本身的参数传递，而非npm run命令的选项。
正确做法是：在运行配置中明确区分“脚本名”和“运行参数”。
- 打开
Run → Edit Configurations…→ 点击+→ 选择NPM -
Package.json：自动识别或手动指定路径 -
Command：填run（不是dev） -
Scripts：填dev（这是要执行的脚本名） -
Options：留空（这里填的是npm命令本身的选项，比如--silent） -
Arguments：填-- --port=4001（注意开头的--必须显式写出，这是告诉npm转发后续参数给脚本）
为什么点运行后终端只输出npm ERR! missing script: build？
这个错误不是脚本不存在，而是WebStorm当前选中的package.json不对——它可能打开了子模块的package.json，或者项目有多个package.json（如monorepo），而WebStorm默认只加载最外层那个。
验证方法：看NPM工具窗口顶部显示的路径，是否和你预期执行脚本的package.json一致。
- 若需运行子目录下的脚本（例如
packages/ui/package.json），不能靠“右键→Run”，必须新建一个NPM运行配置，并在Package.json字段中手动指定完整路径 - Monorepo场景下，建议用
pnpm run build配合-r或-w标志，此时应把Command设为run，Arguments设为build -r，并确保Working directory指向workspace根 - WebStorm 2023.3+ 支持
npm workspaces自动发现，但需在Settings → Languages & Frameworks → Node.js and NPM → Enable npm workspaces support中开启
脚本运行卡住、没日志、或热更新失效，和WebStorm的终端设置有关
WebStorm默认使用内置终端（Terminal）运行npm脚本，但它和系统终端行为不完全一致，尤其涉及stdin读取、进程守护、信号转发时容易出问题。
- 对于
webpack serve、vite这类长期运行的开发服务器，务必勾选运行配置中的Allow parallel run，否则第二次启动会阻塞或报端口占用 - 如果控制台无输出或Ctrl+C无法终止，尝试关闭
Settings → Tools → Terminal → Shell path里的“Override IDE default terminal”选项，改用系统默认shell - 某些脚本依赖
process.stdin.isTTY判断是否交互环境，WebStorm终端默认设为非TTY模式；可在运行配置中添加环境变量：NODE_OPTIONS=--no-warnings或FORCE_COLOR=1辅助调试
WebStorm的npm可视化界面省去了记命令的麻烦，但它的底层仍是调用npm CLI，所有约束和边界都来自npm本身——比如参数透传规则、工作目录继承、多package.json优先级。真正卡住的时候，往往不是UI问题，而是没意识到自己正在哪个上下文里执行命令。
