lerna管理前端模块最佳实践

最近在工做中使用了lerna 进行前端包的管理，效率提高了不少。因此打算总结一下最近几个月使用lerna的一些心得。有那些不足的地方，请包涵。javascript

该篇文章主要包括在使用lerna的一些注意事项，和使用过程当中与其余工具的整合，最终造成的一个最佳实践。前端

package的指的是一个能够经过npm包管理工具发布的一种目录结构，翻译过来感受不太适合，因此就用package来讲明吧。java

前端开发package面临的问题

在最初开开发package的时候，还属于一种刀耕火种的阶段。没有什么自动化的工具。发布package的时候，都是手动修改版本号。若是packages数量很少还能够接受。可是当数量逐渐增多的时候，且这些packages之间还有依赖关系的时候，对开发人员来讲，就很痛苦了。工做不只繁琐，并且须要用掉很多时间。git

举个例子，若是你要维护两个package。分别为module-1,module-2。下面是这两个package的依赖关系。github

// module-1 package.json
{

    "name": "module-1",

    "version": "1.0.0",

    "dependencies": {

        "module-2": "^1.0.0"

    }

}
复制代码

//module-2 package.json
{

"name": "module-2",

"version": "1.0.0",

}
复制代码

在这样的环境下，module-1是依赖module-2的。若是module-2有修改，须要发布。那么你的工做有这些。npm

修改module-2版本号，发布。
修改module-1的依赖关系，修改module-1的版本号，发布。

这还仅仅只有两个package,若是依赖关系更复杂，你们能够想一想发布的工做量有多大。json

什么是lerna?为何要使用lerna?

lerna究竟是什么呢？lerna官网上是这样描述的。bootstrap

A tool for managing JavaScript projects with multiple packages.bash

这个介绍能够说很清晰了，引入lerna后，上面提到的问题不只迎刃而解，更为开发人员提供了一种管理多packages javascript项目的方式。服务器

自动解决packages之间的依赖关系
经过git 检测文件改动，自动发布
根据git 提交记录，自动生成CHANGELOG

使用lerna的基本工做流

环境配置

Git 在一个lerna工程里，是经过git来进行代码管理的。因此你首先要确保本地有正确的git环境。若是须要多人协做开发，请先建立正确的git中心仓库的连接。所以须要你了解基本的git操做，在此再也不赘述。
npm仓库不管你管理的package是要发布到官网仍是公司的私有服务器上，都须要正确的仓库地址和用户名。你可运行下方的命令来检查，本地的npm registry地址是否正确。

npm config ls
复制代码

lerna 你须要全局安装lerna工具。

npm install lerna -g
复制代码

初始化一个lerna工程

在这个例子中，我将在我本地d:/ 根目录下初始化一个lerna工程。

在d:/ 下建立一个空的文件夹，命名为lerna-demo

mkdir lerna-demo
复制代码

cd d:/lerna-demo
lerna init
复制代码

执行成功后，目录下将会生成这样的目录结构。

- packages(目录)
 - lerna.json(配置文件)
 - package.json(工程描述文件)
复制代码

添加一个测试package

默认状况下，package是放在packages目录下的。

// 进入packages目录
cd d:/lerna-demo/packages
// 建立一个packge目录
mkdir module-1
// 进入module-1 package目录
cd module-1
// 初始化一个package
npm init -y
复制代码

执行完毕，工程下的目录结构以下

--packages
	--module-1
		package.json
--lerna.json
--package.json

复制代码

安装各packages依赖这一步操做，官网上是这样描述的。

Bootstrap the packages in the current Lerna repo. Installs all of their dependencies and links any cross-dependencies.

cd d:/lerna-demo
lerna bootstrap
复制代码

在如今的测试package中，module-1是没有任何依赖的，所以为了更加接近真实状况。你可已在module-1的package.json 文件中添加一些第三方库的依赖。这样的话，当你执行完该条命令后，你会发现module-1的依赖已经安装上了。

发布在发布的时候，就须要git 工具的配合了。因此在发布以前，请确认此时该lerna工程是否已经链接到git的远程仓库。你能够执行下面的命令进行查看。

git remote -v
// print log
origin  git@github.com:LittleBreak/lerna-best-practices.git (fetch)
origin  git@github.com:LittleBreak/lerna-best-practices.git (push)
复制代码

本篇文章的代码托管在Github上。所以会显示此远程连接信息。若是你尚未与远程仓库连接，请首先在github建立一个空的仓库，而后根据相关提示信息，进行连接。

lerna publish
复制代码

执行这条命令，你就能够根据cmd中的提示，一步步的发布packges了。

实际上在执行该条命令的时候，lerna会作不少的工做。

-  Run the equivalent of  `lerna updated`  to determine which packages need to be published.
 -  If necessary, increment the  `version`  key in  `lerna.json`.
 -  Update the  `package.json`  of all updated packages to their new versions.
 -  Update all dependencies of the updated packages with the new versions, specified with a  [caret (^)](https://docs.npmjs.com/files/package.json#dependencies).
 -  Create a new git commit and tag for the new version.
 -  Publish updated packages to npm.
复制代码

到这里为止，就是一个最简单的lerna的工做流了。可是lerna还有更多的功能等待你去发掘。 lerna有两种工做模式,Independent mode和Fixed/Locked mode，在这里介绍可能会对初学者形成困扰，但由于实在过重要了，仍是有必要提一下的。 lerna的默认模式是Fixed/Locked mode，在这种模式下，实际上lerna是把工程看成一个总体来对待。每次发布packges，都是全量发布，不管是否修改。可是在Independent mode下，lerna会配合Git，检查文件变更，只发布有改动的packge。

lerna最佳实践

为了可以使lerna发挥最大的做用，根据这段时间使用lerna 的经验，总结出一个最佳实践。下面是一些特性。

采用Independent模式
根据Git提交信息，自动生成changelog
eslint规则检查
prettier自动格式化代码
提交代码，代码检查hook
遵循semver版本规范

你们应该也能够看出来，在开发这种工程的过程的，最为重要的一点就是规范。由于应用场景各类各样，你必须保证发布的packge是规范的，代码是规范的，一切都是有迹可循的。这点我认为是很是重要的。 github代码

工具整合

在这里引入的工具都是为了解决一个问题，就是工程和代码的规范问题。

husky
lint-staged
prettier
eslint