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 步：开始编码

快乐编码