Node.js 项目的文件夹结构

关于您提到的文件夹：

/libs 通常用于自定义类/函数/模块

/vendor 或 /support 包含第 3 方库（使用 git 作为源代码控制时添加为 git 子模块）

/spec 包含 BDD 测试的规范。

/tests 包含应用程序的单元测试（使用测试框架，请参见此处）

注意：由于 NPM 引入了干净的包管理，因此不推荐使用 /vendor 和 /support。建议使用 NPM 和 package.json 文件处理所有 3rd 方依赖项

在构建一个相当大的应用程序时，我推荐以下附加文件夹（特别是如果您使用某种 MVC-/ORM-Framework，如 express 或 mongoose）：

/models 包含您所有的 ORM 模型（在 mongoose 中称为 Schemas）

/views 包含您的视图模板（使用 express 支持的任何模板语言）

/public 包含所有静态内容（图像、样式表、客户端 JavaScript） /assets/images 包含图像文件 /assets/pdf 包含静态 pdf 文件 /css 包含样式表（或由 css 引擎编译的输出） /js 包含客户端 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 样式表

/assets/js 包含您的客户端 CoffeeScript 文件

/assets/css 包含你所有的 LESS/Stylus 样式表

/public/(js|css|img) 包含未由任何编译器处理的静态文件

/src 包含所有服务器端特定的 CoffeeScript 文件

/test 包含所有单元测试脚本（使用您选择的测试框架实现）

/views 包含你所有的明确意见（无论是玉、ejs 还是任何其他模板引擎）

---

因为一个类似的问题，在 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/
└── ...

---

您可以在此处看到我的项目架构中的更多示例：

├── 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 文件夹。

---

假设我们正在谈论 Web 应用程序和构建 API：

一种方法是按功能对文件进行分类。为了显示：

我们正在开发一个图书馆应用程序。在应用程序的第一个版本中，用户可以：

搜索书籍并查看书籍的元数据

搜索作者并查看他们的书籍

在第二个版本中，用户还可以：

创建一个帐户并登录

借书/借书

在第三个版本中，用户还可以：

保存他们想要阅读的书籍列表/标记收藏夹

首先，我们有以下结构：

books
  └─ entities
  │   └─ book.js
  │   └─ author.js
  │
  └─ services
  │   └─ booksService.js
  │   └─ authorsService.js
  │
  └─ repositories
  │   └─ booksRepository.js
  │   └─ authorsRepository.js
  │
  └─ controllers
  │   └─ booksController.js
  │   └─ authorsController.js
  │
  └─ tests
      └─ ...

然后我们添加用户和贷款功能：

user
  └─ controllers
  └─ entities
  └─ services
  └─ ...

loan
  └─ controllers
  └─ ...

然后是收藏夹功能：

favorites
  └─ controllers
  └─ entities
  └─ ...

对于任何接到任务的新开发人员来说，如果任何书籍被标记为收藏，书籍搜索也应该返回信息，很容易看出他/她应该在代码中的哪个位置查找。

然后当产品负责人扫了进来，并惊呼“收藏夹”功能应该完全删除时，删除它很容易。

---

重要的是要注意，对于什么是最佳方法没有达成共识，相关框架通常不会强制执行或奖励某些结构。

我发现这是一个令人沮丧和巨大的开销，但同样重要。它是 style guide issue 的一种低调版本（但 IMO 更重要）。我想指出这一点，因为答案是相同的：你使用什么结构并不重要，只要它定义明确且连贯。

因此，我建议寻找您喜欢的综合指南，并明确该项目是基于此的。

这并不容易，特别是如果你是新手！期望花费数小时研究。您会发现大多数指南都推荐类似 MVC 的结构。虽然几年前这可能是一个可靠的选择，但现在情况并非如此。例如 here's another approach。

---

这是间接的答案，就文件夹结构本身而言，非常相关。

几年前我有同样的问题，采用了一个文件夹结构，但后来不得不做很多目录移动，因为该文件夹的目的与我在互联网上阅读的不同，即特定文件夹的作用在某些文件夹上对不同的人有不同的含义。

现在，已经完成了多个项目，除了在所有其他答案中的解释之外，关于文件夹结构本身，我强烈建议遵循 Node.js 本身的结构，可以在：https://github.com/nodejs/node 中看到。它有很多细节，比如 linter 和其他人，他们有什么文件和文件夹结构以及在哪里。有些文件夹有一个自述文件，解释了该文件夹中的内容。

从上面的结构开始是好的，因为有一天会出现一个新的需求，但是你将有一个改进的空间，因为它已经被 Node.js 本身所遵循，现在已经维护了很多年。

---

只需从 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：开始编码

---