全局安装 TypeScript
命令未找到意味着什么
当你在命令行输入 tsc 却看到 command not found,这不是系统错误。这是缺失。
TypeScript 不是 JavaScript 的语法糖。它是一个需要安装的编译器。没有编译器,.ts 文件就只是文本。
全局安装的意义
工具有两种存在方式:项目内部和系统全局。
项目内的工具随项目生死。你换一个目录,工具就消失。这适合依赖管理,不适合日常使用。
全局工具活在系统路径里。无论你在哪个目录,命令都存在。这是开发者需要的——工具应该像水电一样,随处可用。
解决方案
安装 TypeScript 到全局:
npm install -g typescript
验证安装:
tsc --version
如果你看到版本号,编译器已就位。
全局安装的优势:
- 命令随处可用
- 无需项目依赖即可运行
- 适合快速测试和原型开发
本地安装的优势:
- 项目版本独立
- 团队成员使用相同版本
- 不污染全局环境
实践中,两者并存是常态:全局安装用于日常命令行操作,本地安装用于项目构建流程。参考 依赖注入 理解工具依赖的设计思想。
为什么工具需要全局
开发不是在项目内部完成的。你需要在任何地方创建文件、测试代码、验证想法。
如果每次都要 cd 进项目目录、运行 npx tsc,工具变成了负担。工具的意义是减少摩擦,不是增加步骤。
全局工具让你在命令行的任何位置都能工作。这是效率的前提。
npm vs yarn vs pnpm
不同的包管理器,全局安装命令略有不同:
# npm
npm install -g typescript
# yarn
yarn global add typescript
# pnpm
pnpm add -g typescript
选择你正在使用的那个。命令不同,结果相同——TypeScript 编译器出现在你的系统路径里。
如果安装时遇到权限错误(EACCES 或 permission denied),不要使用 sudo。
更好的方案是配置 npm 的全局安装路径:
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
然后在 ~/.bashrc 或 ~/.zshrc 添加:
export PATH=~/.npm-global/bin:$PATH
重启终端后再次安装。这避免了权限问题,也让全局包管理更清晰。
验证是否成功
安装后,运行任何 TypeScript 命令都应该有响应:
tsc --init # 创建 tsconfig.json
tsc file.ts # 编译单个文件
tsc --watch # 监听模式
如果命令执行,编译器存在。如果依然 command not found,检查两件事:
- 安装是否成功(查看安装日志)
- 系统路径是否包含全局包目录(运行
echo $PATH)
本地项目依然需要 TypeScript
全局安装让命令可用,但项目依然需要本地依赖。
npm install --save-dev typescript
为什么?因为构建工具(webpack、vite、next.js)不会去找你的全局包。它们只看 node_modules。
全局安装是为了你。本地安装是为了构建系统。参考 ESM 模块 了解模块解析的工作原理。
最后
tsc 命令未找到,是因为编译器不在系统路径里。安装到全局,命令随处可用。
工具的价值在于随时能用。全局安装让这成为可能。
Related Posts
Articles you might also find interesting
继承基础配置
配置不需要重复书写。继承机制让每个层次只表达自己的差异。
tsc --noEmit:即时类型反馈
类型错误不应该等到构建时才发现。最快的反馈来自最简单的命令。
Purikura的页面系统
通过五层分层继承复用架构,实现零代码修改的页面生成系统。从类型定义到页面渲染,每一层专注单一职责,实现真正的数据驱动开发。
使用Jest或Vitest作为测试框架有什么区别?
测试框架的选择不是功能列表的比较,而是关于工具哲学的选择。Jest代表完整性,Vitest代表原生性。
让错误浮现
Next.js 构建悬挂问题的根源不在工具,而在掩盖。严格类型检查不是负担,而是质量的守护者。
运行时类型契约
TypeScript 的类型在编译后消失。真正的安全需要在边界处延续类型契约。