Node.js 項目的文件夾結構

Question

我注意到 Node.js 項目通常包含以下文件夾：

/libs, /vendor, /support, /spec, /tests

這些究竟是什么意思？ 它們之間有什么不同，我應該在哪里包含引用的代碼？

Answer 1

關於你提到的文件夾：

• /libs通常用於自定義classes/functions/modules
• /vendor或/support包含第 3 方庫（使用 git 作為源代碼控制時添加為 git 子模塊）
• /spec包含 BDD 測試的/spec 。
• /tests包含應用程序的單元測試（使用測試框架，請參見此處）

注意： /vendor和/support都已棄用，因為 NPM 引入了干凈的包管理。 建議使用 NPM 和 package.json 文件處理所有 3rd-party 依賴項

在構建一個相當大的應用程序時，我推薦以下附加文件夾（特別是如果您使用某種 MVC-/ORM-Framework，如express或mongoose ）：

• /models包含您所有的 ORM 模型（在貓鼬中稱為Schemas ）
• /views包含您的視圖模板（使用 express 支持的任何模板語言）
• /public包含所有靜態內容（圖像、樣式表、客戶端 JavaScript）
  • /assets/images包含圖像文件
  • /assets/pdf包含靜態 pdf 文件
  • /css包含樣式表（或由 css 引擎編譯的輸出）
  • /js包含客戶端 JavaScript
• /controllers包含您所有的 express 路由，由應用程序的模塊/區域分隔（注意：使用 express 的引導功能時，此文件夾稱為/routes ）

我習慣於以這種方式組織我的項目，我認為它很有效。

更新基於 CoffeeScript 的 Express 應用程序（使用connect-assets ）：

• /app包含你編譯的 JavaScript
• /assets/包含所有需要編譯的客戶端資產
  • /assets/js包含您的客戶端 CoffeeScript 文件
  • /assets/css包含你所有的 LESS/Stylus 樣式表
• /public/(js|css|img)包含沒有被任何編譯器處理的靜態文件
• /src包含所有服務器端特定的 CoffeeScript 文件
• /test包含所有單元測試腳本（使用您選擇的測試框架實現）
• /views包含您所有的表達視圖（無論是 jade、ejs 還是任何其他模板引擎）

Answer 2

GitHub上有一個討論，因為一個類似的問題： https : //gist.github.com/1398757

您可以使用其他項目作為指導，在 GitHub 中搜索：

• ThreeNodes.js - 在我看來，似乎有一個特定的結構並不適合每個項目；
• 更輕 - 更簡單的結構，但缺乏一點組織；

最后，在一本書（ http://shop.oreilly.com/product/0636920025344.do ）中提出了這種結構：

├── index.html
├── js/
│   ├── main.js
│   ├── models/
│   ├── views/
│   ├── collections/
│   ├── templates/
│   └── libs/
│       ├── backbone/
│       ├── underscore/
│       └── ...
├── css/
└── ...

Answer 3

您可以在此處查看我的項目架構中的更多示例：

├── Dockerfile
├── README.md
├── config
│   └── production.json
├── package.json
├── schema
│   ├── create-db.sh
│   ├── db.sql
├── scripts
│   └── deploy-production.sh 
├── src
│   ├── app -> Containes API routes
│   ├── db -> DB Models (ORM)
│   └── server.js -> the Server initlializer.
└── test

基本上，邏輯應用程序分離到 SRC 目錄內的 DB 和 APP 文件夾。

Answer 4

假設我們正在談論 Web 應用程序和構建 API：

一種方法是按功能對文件進行分類，就像微服務架構的樣子。 在我看來，最大的好處是可以非常容易地查看哪些文件與應用程序的功能相關。

最好的說明方法是通過一個例子：

---

我們正在開發一個圖書館應用程序。 在應用程序的第一個版本中，用戶可以：

• 搜索圖書並查看圖書的元數據
• 搜索作者並查看他們的書籍

在第二個版本中，用戶還可以：

• 創建一個帳戶並登錄
• 借書/借書

在第三個版本中，用戶還可以：

• 保存他們想要閱讀的書籍列表/標記收藏夾

---

首先我們有以下結構：

books
  ├─ controllers
  │   ├─ booksController.js
  │   └─ authorsController.js
  │
  └─ entities
      ├─ book.js
      └─ author.js

然后我們添加用戶和貸款功能：

user
  ├─ controllers
  │   └─ userController.js
  ├─ entities
  │   └─ user.js
  └─ middleware
       └─ authentication.js
loan
  ├─ controllers
  │   └─ loanController.js
  └─ entities
      └─ loan.js

然后是收藏夾功能：

favorites
  ├─ controllers
  │   └─ favoritesController.js
  └─ entities
      └─ favorite.js

對於任何接受添加任務的新開發人員來說，如果有任何書籍被標記為最喜歡的，書籍搜索也應該返回信息，很容易看到他/她應該在代碼中查看的位置。

然后，當產品負責人沖進來並大聲說應該完全刪除收藏夾功能時，刪除它很容易。

Answer 5

重要的是要注意，對於什么是最佳方法並沒有達成共識，相關框架一般不會強制執行或獎勵某些結構。

我發現這是一個令人沮喪和巨大的開銷，但同樣重要。 這是style guide issue的輕描淡寫版本（但 IMO 更重要）。 我想指出這一點，因為答案是一樣的：只要定義明確且連貫，使用什么結構並不重要。

因此，我建議尋找您喜歡的綜合指南，並明確說明該項目基於此。

這並不容易，特別是如果你是新手！ 預計花費數小時進行研究。 您會發現大多數指南都推薦了類似 MVC 的結構。 雖然幾年前這可能是一個可靠的選擇，但現在情況並非如此。 例如， 這是另一種方法。

Answer 6

這是間接答案，與文件夾結構本身非常相關。

幾年前我有同樣的問題，采用了一個文件夾結構，但后來不得不做很多目錄移動，因為該文件夾的目的與我在互聯網上閱讀的目的不同，即特定文件夾的作用不同的人在某些文件夾上有不同的含義。

現在，做了多個項目，除了所有其他答案中的解釋，關於文件夾結構本身，我強烈建議遵循 Node.js 本身的結構，可以在以下位置看到： https : //github.com/節點/節點。 它非常詳細地介紹了所有內容，例如 linters 和其他人，他們擁有什么文件和文件夾結構以及在哪里。 某些文件夾有一個 README，解釋了該文件夾中的內容。

從上述結構開始是好的，因為總有一天會出現新的需求，但是您將有改進的余地，因為 Node.js 本身已經遵循了它，並且已經維護了很多年。

希望這可以幫助。

Answer 7

只需從 GitHub 克隆 repo

https://github.com/abhinavkallungal/Express-Folder-Structure

這是 node.js express.js 項目的基本結構，已經設置了 MongoDB 作為數據庫，hbs 作為視圖引擎，還有 nodemon，因此您可以輕松設置 node js express 項目

第 1 步：下載或克隆 repo 第 2 步：在任何代碼編輯器中打開 第 3 步：在文件夾路徑上打開終端 第 4 步：在終端npm start運行注釋第 5 步：開始編碼

快樂編碼