Recently, LERNA has been used in my work to manage front-end packages, which has greatly improved my efficiency. So I’m going to summarize some of my experiences with LERna in the last few months. Please bear with me if there are any shortcomings.
This article mainly includes some considerations for using LerNA, as well as a best practice for integrating with other tools.
Package refers to a directory structure that can be published through the NPM package management tool.
Problems facing the front-end development package
At the beginning of the development package, it was still a slash-and-burn stage. There are no automated tools. When you release a package, you manually change the version number. This is acceptable if packages are small. But as the numbers grow and these packages have dependencies, it becomes painful for developers. The work is tedious and takes a lot of time.
For example, if you want to maintain two packages. They are module-1 and module-2 respectively. Here are the dependencies for the two packages.
/ / module - 1 package. Json {" name ":" module 1 ", "version" : "1.0.0", "dependencies" : {" module - 2 ":" ^ 1.0.0 "}}Copy the code
/ / module - 2 package. Json {" name ":" the module - 2 ", "version" : "1.0.0"}Copy the code
In this environment, module-1 is dependent on module-2. If module-2 is modified, publish it. So your job has that.
- Change the version number of Module-2 and release it.
- Change the dependency relationship of module-1, change the version number of module-1, and publish it.
And that’s just two packages, so if the dependencies are more complex, you can imagine how much work it would take to publish.
What is a lerna? Why lerna?
What exactly is Lerna? Lerna’s website describes it this way.
A tool for managing JavaScript projects with multiple packages.
The introduction of lerna not only solves the problems mentioned above, but also provides developers with a way to manage multiple Packages javascript projects.
- Automatically resolve dependencies between packages
- through
git
Detect file changes and publish automatically - According to the
git
CHANGELOG is automatically generated after records are submitted
Basic workflow using Lerna
Environment configuration
- Git in a Lerna project, is through Git code management. Make sure you have the right Git environment locally. Create a link to the correct Git central repository if you need to collaborate with multiple people. Therefore, you need to know the basics of Git operations, which won’t be covered here.
- NPM repository Whether the package you manage is to be published on the official website or on your company’s private server, you need the correct repository address and user name. You can check the local NPM by running the command below
registry
Whether the address is correct.
npm config ls
Copy the code
- Lerna You need to install the Lerna tool globally.
npm install lerna -g
Copy the code
Initialize a LERNA project
In this example, I will initialize a Lerna project in my local root directory.
1. Create an empty folder and name it lerna-demo
mkdir lerna-demo
Copy the code
2. The initialization
cd lerna-demo
lerna init
Copy the code
After the command is executed successfully, this directory structure is generated under the directory.
- Packages - Lerna. json - package.json(project description file)Copy the code
Add a test package
By default, package is placed in the Packages directory.
// Go to package directory CD lerna-demo/packages // create a packge directory mkdir module-1 // go to package directory CD module-1 // Initialize a package NPM init-yCopy the code
The project directory structure is as follows
--packages
--module-1
package.json
--lerna.json
--package.json
Copy the code
4. Install packages dependencies for this step.
Bootstrap the packages in the current Lerna repo. Installs all of their dependencies and links any cross-dependencies.
cd lerna-demo
lerna bootstrap
Copy the code
In the current test package, module-1 does not have any dependencies, so in order to be closer to the real situation. You can add third-party library dependencies to the package.json file in module-1. In this case, when you are done executing this command, you will find that module-1 dependencies are already installed.
5. Release in the release time, you need git tools to cooperate. So before publishing, make sure that the lerna project is already connected to git’s remote repository at this point. You can execute the following command to check.
git remote -v
// print log
origin [email protected]/iNuanfeng/lerna-demo.git (fetch)
origin [email protected]/iNuanfeng/lerna-demo.git (push)
Copy the code
The code for this article is hosted on Github. Therefore, this remote link information is displayed. If you haven’t already linked to a remote repository, create an empty repository on Github and follow the instructions.
lerna publish
Copy the code
By executing this command, you can release Packges step by step as prompted in CMD.
Lerna actually does a lot of work in executing this command.
- 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.
Copy the code
At this point, this is the simplest lerna workflow. But lerna has many more features to discover. Lerna works in two modes,Independent mode and Fixed/Locked mode. This may be confusing for beginners, but it’s important enough to mention. Lerna’s default mode is Fixed/Locked mode, in which lerNA actually treats the project as a whole. Each release of Packges is a full release, with or without modifications. However, in Independent Mode, Lerna will cooperate with Git to check file changes and only release packge with changes.
Lerna Best practices
In order to maximize the impact of LERNA, a best practice was developed based on lerNA’s experience during this period. Here are some features.
- Adopt Independent mode
- According to the
Git
After submitting the information, changelog is automatically generated - Eslint rule checking
- Prettier automatically formats code
- Submit the code, the code checks the hook
- Follow the Semver version specification
As you can see, the most important thing in the process of developing this kind of engineering is the specification. Because of the variety of application scenarios, you need to make sure that the packge you publish is canonical, the code is canonical, and everything is documented. This I think is very important. Lot code
Github link: github.com/iNuanfeng/b…