In the process of project development, how to maintain a management scheme of common component library used by multiple projects
Recently, because of the company’s business requirements, we need to maintain the project component library as an independent project library, but it does not affect the existing directory structure, and it should be easy for daily multi project development and use.
For example, there are currently four projects a, B, C and D, and each project has a component library. However, a considerable part of the components in each component library are duplicated. Therefore, we want to extract the components and maintain them as a separate project library,
Avoid changing four items every time you update a component.
In the process of requirement analysis, two solutions are considered: one is the
NPM private libraryOne is
Git Subtree. The function, advantages and disadvantages, and usage will be discussed in detail below.
In the process of requirement realization, I feel that this requirement is of universal significance. Therefore, I will sort out the implementation process for your reference.
Git subtree is also very effective for splitting the application warehouse of Jushi.
PS: I GitHub, welcome to make friends
+ Node +Vue project (not limited to Vue) +Using git to manage projects (necessary) [git subtree] +Verdaccio & PM2 [NPM private library]
- Multiple projects develop together, but rely on some of the same components
- Modify components in different projects to automatically synchronize to all projects
- To be easy to use, safe, and as much as possible to save time in the development process, can not increase the cost of learning or time costs
Scheme 1: Private Library of NPM
In the daily development, we have all installed countless wheels, which is a good solution to the common code that may be used in daily project work, such as framework class, tool class and common business logic code. If there is a solution in NPM library, we can use wheels in a very open way, but the nature of NPM is open source, and there are always some businesses that are private Relatively high or companies are not allowed to open source code at all. At this time, we need to set up our own NPM private warehouse on the company server.
Related knowledge: make and release an NPM plug-in Author: y2sh
- It is the same as the daily NPM install operation, simple and easy to use
- The cost of one-time erection can be directly used in the future, and the change of personnel level has no effect
- After the component is modified and released, all projects can be used, and the version can be specified
- Daily development is inconvenient, you need to update the component to release any project, update the component version to see the effect
NPM Private Library Tutorial Author: better
Scheme 2: git subtree
Git subtree is a subcommand of GIT. We don’t need to pay attention to its specific definition (refer to Encyclopedia). We only discuss how to use it to meet our needs.
Git subtree can change our current project directory into a sub warehouse by selecting the folder specified by us, so that this directory can be pushed to other project warehouses as an independent warehouse to meet the purpose of multiple projects using the same component library. After it is associated with the specified directory of other projects, the component directory under each project will be updated and pushed, and other projects will receive updates.
- In the same way as git’s multi person collaboration, all projects can be pushed after the associated project is updated
- There is no need to change the existing project catalog
- Component update WYSIWYG, debug effect full
- Multi person cooperation, multi project association, high randomness, may change the project inadvertently affect all projects, so the use of all members must do training instructions
- It must be a project managed by GIT
- It needs some git related knowledge, and the command is relatively long and complex
demo |---- app1 |--- components |---- app2 |--- components
When multiple projects are derived from the warehouse, there must be a part of component library, style library, tool class, etc. of multiple projects that need to be reused. What should I do when I want to separate this part for common use of multiple projects?
Baidu mostly splits the subdirectories of the warehouse into sub warehouses, and likes to have the same name to cause confusion. Here is a detailed explanation of the splitting method of the component library.
The steps are as follows:
Enter the root directory of the warehouse git subtree split -P ./app1/components -b public-lib
Create a new warehouse folder and initialize GIT
mkdir public-lib cd public-lib git init
Pull the warehouse code to the new component warehouse!
git pull ../../demo public-lib ".. / demo" is the original item warehouse directory, because the splitting path has been specified during splitting. Note that the location of the original warehouse. Git file should be written here "Public lib" is the name of the new warehouse Note: This is to directly explain the meaning of this sentence, that is, from the original warehouse to the new warehouse
Git subtree Author: good programming
Git subtree operation tutorial Author: Kuji Daiwa
Considering the advantages and disadvantages of the above two schemes, we finally decided to use them in the development phase
Git SubtreeTo manage and maintain the component library, and consider using it after online
NPM private libraryAdministration. After trying two solutions, the author chooses the above three tutorials as cases to share, and the description is relatively detailed or straightforward (if there is infringement, please contact the author to delete).