## 庫 很多應用需要處理類似的問題，或者說是在不同上下文中重用模塊化組件。Nest提供了一系列方法來實現這個，每個方法在不同層面上面向不同的架構或組織目標來解決問題。 `Nest` 模塊對于提供執行上下文非常有用，它支持在單個應用程序中共享組件。模塊還可以與 `npm` 打包，可以在不同項目中創建可重用庫。這是一種分發可配置、可重用的庫的有效方法，這些庫可以由不同的、松散連接的或不可靠的組織使用(例如，通過分發/安裝第三方庫)。 對于在組織嚴密的組內共享代碼(例如，在公司/項目邊界內)，使用更輕量級的方法來共享組件是很有用的。`Monorepo` 的出現是為了實現這一點，在 `Monorepo` 中，庫以一種簡單、輕量級的方式提供了一種共享代碼的方式。在 `Nest monorepo` 中，使用庫可以方便地組裝共享組件的應用程序。事實上，這鼓勵了對獨立應用程序和開發過程的分解，將重點放在構建和組合模塊化組件上。 ### Nest庫 `Nest` 庫是一個與應用程序不同的 `Nest` 項目，因為它不能獨立運行。必須將庫導入到包含它的應用程序中才能執行它的代碼。本節中描述的對庫的內置支持僅適用于 `monorepos` (標準模式項目可以使用 `npm` 包實現類似的功能)。 例如，組織可以開發一個 `AuthModule`，通過實現控制所有內部應用程序的公司策略來管理身份驗證。 `monorepo` 可以將這個模塊定義為一個庫，而不是為每個應用程序單獨構建那個模塊，或者使用 `npm` 物理地打包代碼并要求每個項目安裝它。當以這種方式組織時，庫模塊的所有使用者在提交 `AuthModule` 時都可以看到它的最新版本。這對于協調組件開發和組裝，以及簡化端到端測試有很大的好處。 ### 創建庫 任何適合重用的功能都可以作為庫來管理。決定什么應該是庫，什么應該是應用程序的一部分，是一個架構設計決策。創建庫不僅僅是將代碼從現有應用程序復制到新庫。當打包為庫時，庫代碼必須與應用程序解耦。這可能需要更多的預先準備時間，并迫使您做出一些設計決策，而這些決策可能不需要更緊密耦合的代碼。但是，當庫可以用于跨多個應用程序實現更快速的應用程序組裝時，這種額外的努力就會得到回報。 要開始創建一個庫，運行以下命令: ```typescript nest g library my-library ``` 當您運行該命令時，庫示意圖會提示您輸入庫的前綴(即別名): ```bash What prefix would you like to use for the library (default: @app)? ``` 這將在工作區中創建一個名為 `my-library` 的新項目。與應用程序類型項目一樣，庫類型項目使用示意圖生成到指定文件夾中。庫是在 `monorepo` 根目錄的 `libs` 文件夾下管理的。`Nest` 在第一次創建庫時創建 `libs` 文件夾。 為庫生成的文件與為應用程序生成的文件略有不同。執行以上命令后，`libs` 文件夾的內容如下: ```bash libs └──my-library │──src │ │── my-library.service.ts │ │── my-library.module.ts │ └── index.ts └── tsconfig.lib.json ``` `nest-cli.json` 文件將在“項目”鍵下為庫添加一個新條目: ```bash ... { "my-library": { "type": "library", "root": "libs/my-library", "entryFile": "index", "sourceRoot": "libs/my-library/src", "compilerOptions": { "tsConfigPath": "libs/my-library/tsconfig.lib.json" } } ... ``` 庫和應用程序之間的 `nest-cli.json` 元數據有兩個區別： - `“type”` 屬性被設置為 `“library”` 而不是 `“application”` - `“entryFile”` 屬性被設置為 `“index”` 而不是 `“main”` 這些差異是構建過程適當處理庫的關鍵。例如，一個庫通過 `index.js` 文件導出它的函數。 與應用程序類型的項目一樣，每個庫都有其自己的 `tsconfig.lib.json` 文件，該文件擴展了根 `tsconfig.json` 文件。 您可以根據需要修改此文件，以提供特定于庫的編譯器選項。 您可以使用 `CLI` 命令構建庫： ```bash nest build my-library ``` ### 使用庫 有了自動生成的配置文件，使用庫就很簡單了。我們如何將 `MyLibraryService` 從 `my-library` 庫導入 `my-project` 應用程序? 首先，注意使用庫模塊與使用其他 `Nest` 模塊是一樣的。`monorepo` 所做的就是以一種導入庫和生成構建現在是透明的方式來管理路徑。要使用 `MyLibraryService` ，我們需要導入它的聲明模塊。我們可以修改 `my-project/src/app.module` 。按照以下步驟導入`MyLibraryModule`。 ```typescript import { Module } from '@nestjs/common'; import { AppController } from './app.controller'; import { AppService } from './app.service'; import { MyLibraryModule } from '@app/my-library'; @Module({ imports: [MyLibraryModule], controllers: [AppController], providers: [AppService], }) export class AppModule {} ``` 請注意，上面我們在模塊導入行中使用了 `@app` 的路徑別名，這是我們在上面的 `nest g library` 命令中提供的前綴。`Nest` 通過 `tsconfig` 路徑映射處理此問題。 添加庫時，`Nest` 會更新全局（`monorepo`）`tsconfig.json`文件的 `“paths”` 鍵，如下所示： ```json "paths": { "@app/my-library": [ "libs/my-library/src" ], "@app/my-library/*": [ "libs/my-library/src/*" ] } ``` 因此，簡單地說，`monorepo` 和庫特性的組合使將庫模塊包含到應用程序中變得簡單和直觀。 這種機制也支持構建和部署組成庫的應用程序。導入 `MyLibraryModule` 之后，運行 `nest build` 將自動處理所有的模塊解析，并將應用程序與任何庫依賴項捆綁在一起進行部署。`monorepo` 的默認編譯器是 `webpack`，因此生成的分發文件是一個文件，它將所有轉換后的 `JavaScript` 文件打包成一個文件。