フロントエンドプロジェクトのコンポーネント化について

フロントエンドプロジェクトのコンポーネント化について
前に詳しく話したフロントエンドプロジェクトのコンポーネント化は、コンポーネント化とプライベートnpm倉庫を参照して、今日はさらにフロントエンドプロジェクトのコンポーネント化についてお話しします.
1.前のアセンブリ化
ディレクトリ構造:

-project1     #   1
-project2     #   2
-component1   #   1
-component2   #   2

project1のpackage.json:

{
  "dependencies": {
    "@yourCompany/component1": "^0.0.1",
    "@yourCompany/component2": "^0.0.1"
  }
}

コードで使用:

import component1 from '@yourCompany/component1';

2.従来のコンポーネント化方式での問題点

コンポーネントの更新は面倒で、特にビジネスとの結合が深いコンポーネントでは、頻繁に更新すると

が頭を悩ませることがあります.

コンポーネントが多すぎると、管理が疲れます.各コンポーネントは個別のプロジェクトであり、独立した構築環境があります.

コード量の小さいコンポーネントに対して、単独のプロジェクトをして、本当に少し大きくて

を使っています.
3.その他の項目の構成化方式
上記の問題に対して、もう一つの方法はよく解決できます.
ディレクトリ構造:

-project1     #   1
-project2     #   2
-components   #       

componentsコンポーネント集合プロジェクトのディレクトリ構造:

- src/             #      
  - component1     #   1
  - component2     #   2
  - component3     #   3
  - ...

- package.json
- README.md
- CHANGELOG.md
- .eslintrc.js
- .stylelintrc.js
- .prettierrc.js
- ...

componentsディレクトリソフトリンクproject1ディレクトリの下:
(注意:project1の.gitignoreに/componentsを加える必要があります)

#     linux   ，windows   
cd project1
ln -s ../components ./

project1プロジェクトのディレクトリ構造:

- src/             #      
- components/      #       （   ）

- package.json
- README.md
- CHANGELOG.md
- .eslintrc.js
- .stylelintrc.js
- .prettierrc.js
- ...

コードで使用:

import component1 from 'relative/path/to/components/src/component1';

4.両方式の選択
上記の2つの方法はそれぞれ利点があり、組み合わせて使用することができます.
大きな、頻繁に更新されないコンポーネントはnpmパッケージの方式を使用することができ、小さい、頻繁に更新されたソフトリンクプロジェクトの方式を使用することができる.
に続く
その他のブログhttps://github.com/senntyou/blogs
作者:深予之(@senntyou)
自由転載-非商用-非派生-署名保持(クリエイティブ共有3.0ライセンス)