讲如何合理搭建前端项目海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

通过上一的学习，我们分析了前端构建工具webpack的底层原理，在理解原理再来探索构建

工具的具体应用——如何合理前端项目。当然，前端项目并不只是使用构建工具这么简单，本

从项目组织、代码规范2个方面来进行分析。

项目组织

考虑这样一个场景，在开发项目projectA的时候，发现其中的codeX也可以用于项目projectB，最简

单直接的处理方式就是把codeX的代码直接到projectB下，按照“三次原则”（三次原则是指同一

段代码被使用到3次时再考虑抽象）这种处理方式没什么问题。但如果此时项目projectC和projectD

也会用到codeX，那么这种方式起来会很麻烦。

有经验的工程师会想到将codeX发布成模块，作为依赖模块引入所需的项目中。此时对于codeX会涉

及两种组织代码的方式：multirepo和monorepo。

multirepo

multirepo就是将项目中的模块拆分出来，放在不同的仓库中进行独立管理。例如，用于Node.js的

Web框架Koa，它依赖的模块koa-convert和koa-compose分别拆分成了两个仓库进行管理。

这种方式的好处是保证仓库的独立性，方便不同团队对应的仓库代码，可以根据团队情况选择擅长

的工具、工作流等。

但这种方式也会存在一些问题，具体如下。

开发调试及版本更新效率低下。比如在仓库A用到的仓库B中发现了一个bug，就必须到仓库B

里修复它、打包、发版本，然后再回到仓库A继续工作。在不同的仓库间，你不仅需要处理不同

的代码、工具，甚至是不同的工作流程；还有，你只能去问这个仓库的人，能不能为你做出改

变，然后等着他们去解决。

团队技术选型分散。不同的库实现风格可能存在较大差异（比的库依赖Vue，有的依赖

React），还有可能会采用不同的测试库及校验规则，起来比较。

而monorepo方式恰好就能解决这些问题。

monorepo

monorepo就是将所有相关的模块放在同一个项目仓库中。这种方式在管理上会更加方便，项目所有代

码可以使用统一的规范及构建、测试、发布流程。

很多著名的开源项目都采取了这种管理方式，比如开源项目babel，它依赖的模块都放在了packages

下。

babel的依赖模块

通过查看babel项目，发现根下有一个lerna.json的配置文件，这是开源工具lerna的配置文件。

lerna是一个用于管理带有多个包的JavaScript项目工具，用lerna管理的项目会有3个文件：

packages、learna.json文件和package.json文件。通过lerna命令行工具在初始化项目的时候

就可以创建它们。

lerna支持两种模式，分别是Fixed/Locked和t

模式。

Fixed/Locked模式为默认模式，babel采用的就是这种模式，该模式的特点是，开发者执行lerna

publish后，lerna会在lerna.json中找到指定version版本号。如果这一次发布包含某个项目的更

新，那么会自动更新version版本号。对于各个项目相关联的场景，这样的模式非常有利，任何一个项

目大版本升级，其他项目的大版本号也会更新。

t

模式顾名思义，各个项目都是相互独立。开发者需要独立管理多个包的版本更新。也就是

说，我们可以具体到更新每个包的版本。每次发布，lerna会配合Git，检查相关包文件的变动，只发布

有改动的package。

虽然众多开源项目采用了monorepo，但它也并不是最完美的代码组织方式，也会带来一些问题，比如

由于将多个模块集中在一个仓库中会导致仓库体积变大，结构也会变得更复杂。而monorepo也

需要额外的工具来管理各个模块，这意味着相对multirepo而言会有一定的学习成本。

代码规范

什么样的代码才