当前位置：网站首页>Monorepo management methodology and dependency security

Monorepo management methodology and dependency security

2022-07-05 20:49:00 【Chenai】

Preface

Recently I saw 、 Experienced a lot No specification Of monorepo Warehouse and scene , There are many mistakes , Are the same as my own failure experience , Because they all end up 、 It will soon become irreversible historical debt .

In order to avoid historical debt , modern monorepo Some behaviors of 、 What is the bottom line of norms ？

Text

Use the latest version of pnpm

Due to the existence of dependent ascension 、 Ghost dependency problem , At present, the only and best solution is pnpm , About the critical point of model selection , May refer to ：

《 pnpm monorepo Critical point of technology selection （Critical adoption）》

meanwhile , You should use the latest version of pnpm （ Now it is v7 ）, If you are currently using v6 , May refer to ：

《 Chat pnpm v6 l v7 Embrace change and experience 》

In configuration , pnpm v7 Yes peer deps The default strict setting of requires the following options ：

# .npmrc
strict-peer-dependencies=false

See pnpm > .npmrc > strict-peer-dependencies .

in addition , In response to an emergency , Often pnpm.overrides And other options , For example, when attacked by the supply chain, it is necessary to unify a globally dependent version ：

// package.json
{
    
  "pnpm": {
    
    "overrides": {
    
      "some-dep": "1.0.0"
    }
  }
}

Use pnpm monorepo management

Every project will have an inflationary trend , It means that the monomer design is no longer in line with modern FE Project development methodology . Even single package applications should use monorepo ：

SDK ： about sdk project , The future needs to be expanded and will inevitably face monorepo Subcontracting decoupling , And local testing 、 Debugging requires example project , adopt pnpm Of workspace:* Protocol Links sdk Subpackages can well support immediate modification to debug , Completely avoid link tedious 、 It's not easy to use .
Project： For business projects , In the future, we will inevitably face the situation that the project expansion requires extraction and reuse , therefore monorepo Design is inevitable , Otherwise, it will face the painful cost of the overall mobile rectification of the project and the repeated contracting and revision of the version number of multiple warehouses .

The initial design of the warehouse is very important , He determines the state that your project will always maintain in the future , From the beginning, we should face the future , Instead of solving it after encountering it , Otherwise, move all files and destroy commit history Don't say , There will also be insurmountable obstacles to development due to many path factors and other inherent historical debts .

monorepo Global does not install dependencies

Be careful with monorepo The top floor of , Because the top-level dependency will be shared by all sub packages , Form invisible ghost dependence , And hard to detect ：

except npm-run-all 、cross-env 、 self-built script Tool dependencies such as script packages that are only used in local development environments , Try to avoid installing any production dependencies on the top .

For a while, the top floor is cool , No reason can be found for the project error , Remember not to abuse the top , Otherwise, it will cause irreversible historical debt .

Using other sub packages must be placed in dependencies in

When you need to use other sub package code in a sub package , It must be added to package.json#dependencies in , Use workspace:* Protocol Links ：

// package.json
{
    
  "dependencies": {
    
    "@scope/some-dep": "workspace:*"
  }
}

notes ： Remember not to install this package in the global , Otherwise, with the cooperation of many people, ghost dependence will occur over time 、 Version inconsistency and other irreversible historical debt .

Use type Check

Make sure there are no non-human things in your warehouse type error ：

SDK： about SDK project , belong The test link / CI Use in tsc --noEmit Carry out full warehouse type Check .
Project： For business projects , Except that it can be used tsc --noEmit Outside , You can also use fork-ts-checker-webpack-plugin The webpack Plug-ins to regulate behavior during the coding phase .

This can greatly reduce errors 、 Unstable coding , And prevent the use of non-existent dependent imports .

Use workspace:* Protocol associated sub package

When codes are referenced between packages , You should use workspace:* To link subpackages , Not the specific version number , This can prevent the omission and conflict of the modified version when multiple people work together .

If there is a contracting scenario , You should use changesets To contract , This tool will help you upgrade the version automatically 、 produce CHANGELOG 、 Auto replace workspace:* For the specific version 、 Automatically maintain version consistency , Benchmarking best practices .

About changesets You can search and learn the basic content of , For advanced content, please refer to ：

《 monorepo The foundation of workflow changesets Open and advanced （Speeches）》

Use turborepo Avoid circular dependence

When building sub packages , In order to achieve on-demand 、 The best construction path , You should use turborepo Directed construction ,turbo It will automatically help you check whether there is circular dependency , If there is an error, exit .

It should be noted that pnpm Native supported directed build pnpm -r --filter Circular dependency not detected .

in addition , because turbo It is inconvenient to carry extra parameters when executing commands （ A classic scenario is to build packages locally declarationMap Easy to locate , The cloud doesn't need ）, So you can write a script to judge process.env.CI Whether there is （ You need to build the image of the environment to support this variable ）, Then use it locally pnpm -r --filter Build pre dependency , Cloud use turbo structure .

About turborepo The relevant references of can be seen ：

Subcontracting thinking 、 Multiple decoupling sub packages

Split thinking

Now that it's used monorepo , It has inherent decoupling advantages , You should not make the content into a monolith , We should unpack more molecules , Try to extract and reuse the common parts . We can do it in different fields , The higher the degree of decoupling , The less likely it is to generate circular dependency and circular introduction , The project is more halal .

For the hot update of the extracted reference code package, you need to use monorepo Redirect to solve , See ：

《 Monorepo Silky methodology ： Reference module hot update 》

notes ： Business projects still need to be separated , After all, you don't do Sooner or later, it will be added by others , Don't pursue extreme reuse .

Domain thinking

Should open more workspace Folder , Sub domain management , Instead of adding , such as ：

apps/* ： Put all business items under this folder .
libs/* ： Put all under this folder sdk And reuse components .
templates/* ： This folder contains template items .
configs/* ： Put all under this folder eslint / tsconfig And other public configured sub packages .

Example ：

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'examples/*'
  - 'libs/*'
  - 'configs/*'
  - 'templates/*'
  - 'scripts'
  # ...

For example, there are document stations , Configuration sharing , It should all be made into sub bags , Instead of adding files to the global , Otherwise, huge historical debts will be incurred .

notes ： All projects should be sub packages , Don't top root It's a project , It's still open. workspace , Not only global dependencies will affect sub packages , It will also lead to irreversible historical debt ！

summary

It is because monorepo It is a blueprint vision that may continue to expand in the future , So all kinds of norms and bottom lines are particularly important , Otherwise there is one “ Error element ” , Soon all collaborators will follow 、 Reproduce , Lead to the destruction of the whole project .