漯河市网站建设_网站建设公司_网站制作_seo优化

从零开始搭建你的第一个 Nx 工作区：手把手带你跑通全流程

你有没有遇到过这样的场景？团队里多个前端项目各自为政，配置重复、代码无法复用、构建越来越慢……随着业务膨胀，维护成本像雪球一样越滚越大。这时候，是时候引入一个真正能“治本”的工程化方案了。

Nx 就是为此而生的利器。它不只是个脚手架，而是一整套智能化的 monorepo 管理体系，让你在复杂系统中依然保持敏捷开发的节奏。今天，我们就抛开理论堆砌，直接动手——从环境准备到应用启动，一步步创建属于你的第一个 Nx 项目，并让它真正跑起来。

先别急着写代码，我们先搭好舞台

为什么选择npx create-nx-workspace？

很多新手会纠结：“我该全局安装 Nx CLI 吗？”答案很明确：不需要。

Nx 官方推荐使用npx create-nx-workspace@latest来初始化项目，原因很简单：

• 无需全局污染：每次都能用最新稳定版，避免本地版本陈旧或冲突
• 即用即走：适合一次性初始化操作，干净利落
• 自动依赖管理：内置包管理器（npm/yarn/pnpm）选择逻辑，适配性强

来吧，打开终端，执行这行命令：

npx create-nx-workspace@latest myorg

💡小贴士：这里的myorg是工作区名称，通常代表你的组织名。你可以替换成acme-project或其他你喜欢的名字。

执行后你会进入交互式引导流程：

1. 选择初始模板
   -empty：空工作区（推荐初学者选这个）
   -react,angular,vue等：带默认应用的模板

2. 输入应用名称（可选）
   如果你希望立刻生成一个应用，可以在这里命名；否则后续也能手动添加。

3. 选择前端框架和样式方案
   比如选 React + SCSS，Nx 会自动配置对应的构建工具链。

4. 是否启用 Nx Cloud？
   初次学习建议选否。Nx Cloud 是用于远程缓存与分布式计算的增值服务，在 CI/CD 中非常强大，但本地开发初期不必开启。

等几分钟，依赖安装完成，你就拥有了一个结构清晰、配置齐全的 Nx 工作区！

进去看看：Nx 的目录长什么样？

初始化完成后，进到项目根目录瞧一瞧：

cd myorg ls -la

你会看到类似下面的结构：

myorg/ ├── apps/ │ └── my-first-app/ # 我们刚生成的应用 ├── libs/ # 所有共享库将放在这里 ├── tools/ # 自定义脚本、生成器等扩展内容 ├── nx.json # Nx 的核心调度中心 ├── tsconfig.base.json # 全局 TypeScript 路径映射 ├── package.json # 根级依赖和脚本入口 └── project.json # 新版 Nx 使用分散配置，每个项目有自己的 json 文件

别被这么多文件吓到，我们重点看三个关键配置。

1.nx.json：整个工作区的“大脑”

它决定了任务如何运行、哪些变更会影响构建、要不要并行执行等等。比如这段配置：

{ "defaultBase": "main", "targetDefaults": { "build": { "dependsOn": ["^build"], "inputs": ["production", "^production"] } } }

什么意思？

• "dependsOn": ["^build"]表示：构建当前项目前，必须先构建它的依赖项。
• "inputs"定义了影响缓存的因素，包括自身和上游项目的生产环境输入。

这就是 Nx 实现精准增量构建的秘密武器：只有真正变化的部分才会重新编译。

2.tsconfig.base.json：让跨项目引用像 npm 包一样自然

打开一看，你会发现一段路径映射：

{ "compilerOptions": { "paths": { "@myorg/ui-components": ["libs/ui-components/src/index.ts"] } } }

这意味着，只要你在任何地方写下：

import { Button } from '@myorg/ui-components';

TypeScript 就知道去哪里找这个模块，而且类型推导完全正常！再也不用手动相对路径跳来跳去了。

3.project.jsonvsworkspace.json：新旧模式之争

较新的 Nx 版本采用分散式配置，每个项目都有自己的project.json，例如：

// apps/my-first-app/project.json { "targets": { "serve": { "executor": "@nrwl/vite:dev-server" }, "build": { "executor": "@nrwl/vite:build" } } }

相比老式的集中式workspace.json，这种方式更灵活，更适合大型项目拆分治理。

动手！生成你的第一个 React 应用

假设我们在初始化时选的是empty工作区，现在需要手动加一个应用。

运行这条命令：

npx nx g @nrwl/react:application my-first-app --style=scss --routing=true

分解一下参数含义：

执行完后，Nx 会在apps/my-first-app/下创建完整的 React 项目骨架：

• src/app/App.tsx—— 主组件
• src/main.tsx—— 入口文件
• index.html—— HTML 模板
• 测试文件、Vite 配置、ESLint 规则全都有

更重要的是，它已经自动注册到了 Nx 的项目清单中。

想知道现在有几个项目？试试这个命令：

npx nx show projects

输出应该是：

my-first-app

如果你想查看所有可用的生成器（generators），可以用：

npx nx list

会列出所有已安装插件及其支持的功能，比如@nrwl/react支持生成application、component、library等。

启动开发服务器，看看页面出来了没

一切就绪，现在启动服务：

npx nx serve my-first-app

或者简写：

npx nx s my-first-app

Nx 会根据配置自动调起 Vite 开发服务器，默认监听http://localhost:4200。

浏览器打开，你应该能看到熟悉的欢迎页：“Welcome to my-first-app!” ✅

热更新也已就绪，改一行代码，页面瞬间刷新，丝滑无比。

创建共享库：告别复制粘贴时代

想象一下，你有两个应用：后台管理系统和移动端 H5 页面，都需要用同一个按钮组件。传统做法是复制两份代码，结果一处修改就得改多处，极易出错。

Nx 的解法简单粗暴又高效：抽成共享库。

运行命令生成一个 UI 组件库：

npx nx g @nrwl/react:library ui-components --publishable --importPath=@myorg/ui-components

关键参数说明：

• --publishable：表示这个库未来可以发布到私有 NPM 仓库（会生成package.json）
• --importPath：设置导入别名，确保 IDE 能正确识别路径

生成后的结构如下：

libs/ui-components/ ├── src/ │ ├── lib/ │ │ └── button.tsx │ └── index.ts # 统一导出接口 ├── package.json └── jest.config.ts

在index.ts中导出组件：

// libs/ui-components/src/index.ts export { Button } from './lib/button';

然后回到应用中使用它：

// apps/my-first-app/src/app/App.tsx import { Button } from '@myorg/ui-components'; export function App() { return ( <div> <h1>Welcome to My First App</h1> <Button label="Click Me" /> </div> ); }

保存后，开发服务器自动热重载，按钮立马出现在页面上 🎉

而且全程享受类型检查，如果Button组件要求label是字符串，你传了个数字，TS 编译器马上报错。

为什么说 Nx 能拯救大型项目？

痛点一：配置满天飞，改个规则要改十个地方？

以前每个子项目都有一套.eslintrc、tsconfig.json、prettier.config.js……一旦想统一规范，就得挨个改。

Nx 怎么做？一套配置管全家。

根目录下的eslint.config.js或.eslintrc.json控制所有项目的 lint 规则，修改一次，全局生效。

痛点二：CI 构建越来越慢，等半小时才跑完？

Nx 内置计算任务缓存机制（computation caching）。

当你运行：

npx nx affected:build

Nx 会分析 Git 变更，只构建那些“受影响”的项目。如果你只改了一个 UI 库，那只有依赖它的应用才会重新构建，其余直接复用缓存。

结合 Nx Cloud 更是能实现远程缓存共享，团队成员之间也能复用彼此的构建结果，CI 时间从 30 分钟降到 3 分钟不是梦。

痛点三：项目太多，谁依赖谁根本理不清？

试试这个神奇命令：

npx nx graph

Nx 会启动一个本地可视化界面，展示所有项目之间的依赖关系图谱：

• 哪些应用用了哪个库？
• 是否存在循环依赖？
• 某个工具库被多少个项目引用？

一目了然，防患于未然。

实战建议：这样用 Nx 更顺手

1. 命名要有意义

不要叫lib1、app2，而是采用语义化命名：

• feature-auth—— 认证功能模块
• util-formatters—— 格式化工具函数
• ui-layout—— 布局组件库

便于团队协作理解。

2. 控制边界访问

Nx 提供@nrwl/nx/enforce-module-boundariesESLint 规则，可以在eslint.config.js中启用：

{ rules: { '@nrwl/nx/enforce-module-boundaries': [ 'error', { enforceBuildableLibDependency: true, allow: [], depConstraints: [ { sourceTag: 'type:feature', onlyDependOnLibsWithTags: ['type:feature', 'type:util'] } ] } ] } }

防止某些层随意跨越访问，保持架构整洁。

3. 渐进式迁移已有项目

如果你已经有多个独立仓库，也不必推倒重来。

Nx 支持通过nx migrate和workspace-schematic工具逐步将现有项目合并进 monorepo，风险可控，平滑过渡。

最后一句真心话

掌握 Nx 并不意味着你要立刻重构整个公司架构。它的真正价值在于：当你面对复杂性时，手里有一把趁手的刀。

无论是快速搭建一个多应用原型，还是支撑百人团队协同开发，Nx 都能在不影响开发体验的前提下，帮你把工程化做到极致。

所以，别再犹豫了。回到终端，敲下那句：

npx create-nx-workspace@latest my-first-workspace

然后告诉我，你的第一个 Nx 应用跑起来了吗？欢迎在评论区分享你的实践心得 😊