background

In the development of large-scale projects, we usually encounter the problem that the same project depends on different component packages, and at the same time, different component packages will depend on each other, so how to manage and organize these dependency packages is an urgent problem.

The solutions we currently have are: Multirepo(multiple dependencies managed independently by Git) and Monorepo(all dependencies put into a single project).

The downside of Multirepo is that after each library change, it needs to be published online, then reinstalled, packaged, published, and finally updated in the project, making it more difficult to maintain if the dependencies are more complex. The biggest disadvantage of Monorepo is that it is not easy to reuse and share code.

To solve this problem, Lerna is a tool that can easily manage JavaScript projects with multiple packages. At the same time, for the developers and maintainers of component packages, it is particularly important to build component documents and demos in order to make other team members better understand and use the components we develop.

Let’s make a summary of the points mentioned above:

  • How are organizational dependencies and their versioning issues managed in large projects
  • How to efficiently and cheaply build easy-to-use component documentation
  • How do I configure the ESLint code specification and code submission specification

I will give answers to the above questions one by one. If you want to see an actual case, you can refer to:

  • Best – the CPS | based on lerna + dumi build package management practice

How are organizational dependencies and their versioning issues managed in large projects

This problem is mainly solved with the LERna tool I mentioned above. Lerna is used in Babel, create-React-app, vue-CLI, etc.

Without lerna, the organization of our different libraries might be as follows:

Library organization structure with LerNA:

The above two diagrams are my sketches, which can basically compare the differences before and after using LERna. Lerna is used to split multiple projects or modules into multiple packages and put them into a Git repository for management. We can easily manage different projects using the commands it provides, as follows:

  • Lerna Boostrap automatically resolves dependencies between packages. Dependencies within packages are directly associated in symlink mode
  • Lerna publish relies on Git to detect file changes, automatically publish, and manage version numbers
  • Lerna create Creates a package managed by LerNA
  • Lerna clean deletes the node_modules directory under all packages, or the node_modules directory under specified packages

At the same time, Lerna will automatically generate Changelog according to git submission records. Of course, Lerna also provides a lot of useful commands that you can learn from on the official website.

I’m going to take you from scratch to build a multi-package project managed by Lerna.

Above is our package dependencies. First we need to install lerna globally.

Project initialization

$ git init best-cps && cd best-cps
$ lerna init
Copy the code

Create three packages

$ lerna create LibA && lerna create LibB && lerna create BaseUI
Copy the code

The directory structure for each package created is as follows:

├─ ├─ class.txt TXT ├─ class.txt TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT TXT

Install the corresponding package dependencies

Based on the dependencies of the 3 packages shown above, we need to target the installation as follows:

$ lerna add LibA --scope=LibB
Copy the code

Since LibB relies on LibA, we can specify the installation scope with –scope when using lerna Add. For example, BaseUI relies on both LibA and LibB packages, we can use the following command:

$ lerna add LibA LibB --scope=BaseUI
Copy the code

We can do the rest as described above. After we have written the corresponding package code, we can also use:

$ lerna publish
Copy the code

One-click publishing of packages to NPM, where the version numbers of all packages are updated according to the version numbers in lerna.json, depending on the management mode we choose. However, it is important to note that the LERna version update supports two modes:

  • Fixed/locked mode (default, specify version number)

This pattern automatically bundles all packages package versions together, and significant changes to any one or more packages will result in all packages version numbers being updated.

  • Independent mode

In independent mode, init requires the option –independent. This pattern allows consumers to change the version number individually for each package. When lerna publish is executed each time, the version number to be upgraded will be asked one by one for all packages that have been updated. The base version is the version number in its package.json. In this case, the version number of lerna.json does not change and defaults to independent. We can specify when lerNA is initialized:

lerna init --independent
Copy the code

Specific cases can be referred to: github.com/MrXujiang/b…

How to efficiently and cheaply build easy-to-use component documentation

For component documentation, there are many open source tools in the market, such as VUe-press, Storybook, Docz, etc. Since most of my recent projects are react, I used Dumi here. I have shared with you the use of Dumi in implementing the sliding captcha component. Please refer to my previous article:

  • Develop a lightweight sliding verification code plug-in from scratch

Here’s what the document site looks like when DUMi is integrated into lerna:

How do I configure the ESLint code specification and code submission specification

Eslint code specification I think everyone is familiar with, we just need to install the corresponding plug-in and write the corresponding rule configuration file, here is a simple example:

// .eslintrc.js
module.exports = {
  extends: [require.resolve('@umijs/fabric/dist/eslint')].rules: {
    'import/no-extraneous-dependencies': 0.'import/no-unresolved': 0,}};Copy the code

After the configuration, we need to set the detection timing, such as runtime detection or commit detection. Due to personal habits and efficiency problems, I adopted commit detection, that is, when the developer completes the function development and executes git commit detection. We can use Githook to do pre-commit detection by adding the following command to package.json:

"gitHooks": {
    "pre-commit": "npm run lint:js"
  },
Copy the code

After configuration, we randomly write a line of non-standard code, and then submit, the terminal will display the following message:

From the console, we can find out where and why the code isn’t conforming, and if we hadn’t made the adjustments, the code wouldn’t have been committed. This way, we can improve the code quality and error probability, which is very valuable in the long run.

Gtihooks, which can help you customize the actions you need to perform at different stages of code submission, such as checking before code submission, code submission specification, etc.

  • pre-commit
  • prepare-commit-msg
  • commit-msg
  • post-commit
  • pre-rebase
  • post-merge
  • pre-receive
  • update

For those interested, visit Githooks.com for more githooks content.

We also need to unify the code submission specification so that the team can see what is being committed every time, especially when multiple people are working together. Here are a few common examples of submission irregularities:

'git commit -m ':update' git commit -m 'fix a bugCopy the code

The reason why the above submission format is not uniform or difficult to understand the submission information is due to the lack of specification constraints, so for large projects or multi-person collaborative projects, it is best to standardize, so as to avoid a lot of unnecessary trouble in advance.

To implement the detection of the information submitted by engineers, you need to use the githooks commit-msg. The specific configuration is as follows:

"gitHooks": {
    "pre-commit": "npm run lint:js"."commit-msg": "node ./commitlint.js verify-commit"
  }
Copy the code

The rest is commitlint.js, which is a nodeJS script I wrote to check whether the submitted information is valid or not. You can also use this script to define your own submission specifications, as follows:

As we can see, when we submit a non-conforming message, the terminal console prints the following message and terminates the program to continue.

Through the above configuration, the written code and submitted information of different team members will be very unified and standardized, and the overall quality of the project will be improved to a certain extent.

The last

If you are interested in visual scaffolding or low code/zero code, please refer to my previous articles or share your thoughts in the comments section, and explore the real technology of the front end.

More recommended

  • Develop a lightweight sliding verification code plug-in from scratch
  • How to design a visual platform component store?
  • Build engine from zero design visualization large screen
  • Build desktop visual editor Dooring from zero using Electron
  • (low code) Visual construction platform data source design analysis
  • Build a PC page editor pc-dooring from scratch
  • How to build building blocks to quickly develop H5 pages?