Node.js 项目的文件夹结构

Folder structure for a Node.js project

提问by u443966

I notice that Node.js projects often include folders like these:

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

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

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

What exactly do these mean? What's the different between them, and where should I include referenced code?

这些究竟是什么意思？它们之间有什么不同，我应该在哪里包含引用的代码？

回答by schaermu

Concerning the folders you mentioned:

关于你提到的文件夹：

• /libsis usually used for custom classes/functions/modules
• /vendoror /supportcontains 3rd party libraries (added as git sub-module when using git as source control)
• /speccontains specifications for BDD tests.
• /testscontains the unit-tests for an application (using a testing framework, see here)

• /libs通常用于自定义 classes/functions/modules
• /vendor或/support包含 3rd 方库（在使用 git 作为源代码控制时添加为 git 子模块）
• /spec包含 BDD 测试的规范。
• /tests包含应用程序的单元测试（使用测试框架，请参见 此处）

NOTE: both /vendorand /supportare deprecated since NPM introduced a clean package management. It's recommended to handle all 3rd-party dependencies using NPM and a package.json file

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

When building a rather large application, I recommend the following additional folders (especially if you are using some kind of MVC- / ORM-Framework like expressor mongoose):

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

• /modelscontains all your ORM models (called Schemasin mongoose)
• /viewscontains your view-templates (using any templating language supported in express)
• /publiccontains all static content (images, style-sheets, client-side JavaScript)
  • /assets/imagescontains image files
  • /assets/pdfcontains static pdf files
  • /csscontains style sheets (or compiled output by a css engine)
  • /jscontains client side JavaScript
• /controllerscontain all your express routes, separated by module/area of your application (note: when using the bootstrapping functionality of express, this folder is called /routes)

• /models包含您所有的 ORM 模型（Schemas在 mongoose 中调用）
• /views包含您的视图模板（使用 express 支持的任何模板语言）
• /public包含所有静态内容（图像、样式表、客户端 JavaScript）
  • /assets/images包含图像文件
  • /assets/pdf包含静态pdf文件
  • /css包含样式表（或由 css 引擎编译输出）
  • /js包含客户端 JavaScript
• /controllers包含所有的 express 路由，由应用程序的模块/区域分隔（注意：当使用 express 的引导功能时，这个文件夹被称为/routes）

I got used to organize my projects this way and i think it works out pretty well.

我习惯于以这种方式组织我的项目，我认为效果很好。

Update for CoffeeScript-based Express applications (using connect-assets):

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

• /appcontains your compiled JavaScript
• /assets/contains all client-side assets that require compilation
  • /assets/jscontains your client-side CoffeeScript files
  • /assets/csscontains all your LESS/Stylus style-sheets
• /public/(js|css|img)contains your static files that are not handled by any compilers
• /srccontains all your server-side specific CoffeeScript files
• /testcontains all unit testing scripts (implemented using a testing-framework of your choice)
• /viewscontains all your express views (be it jade, ejs or any other templating engine)

• /app包含你编译的 JavaScript
• /assets/包含所有需要编译的客户端资产
  • /assets/js包含您的客户端 CoffeeScript 文件
  • /assets/css包含你所有的 LESS/Stylus 样式表
• /public/(js|css|img)包含未被任何编译器处理的静态文件
• /src包含所有服务器端特定的 CoffeeScript 文件
• /test包含所有单元测试脚本（使用您选择的测试框架实现）
• /views包含您所有的表达意见（无论是 jade、ejs 还是任何其他模板引擎）

回答by Paulo Oliveira

There is a discussion on GitHub because of a question similar to this one: https://gist.github.com/1398757

GitHub上有一个讨论，因为一个类似的问题：https: //gist.github.com/1398757

You can use other projects for guidance, search in GitHub for:

您可以使用其他项目作为指导，在 GitHub 中搜索：

• ThreeNodes.js - in my opinion, seems to have a specific structure not suitable for every project;
• lighter - an more simple structure, but lacks a bit of organization;

• ThreeNodes.js - 在我看来，似乎有一个特定的结构并不适合每个项目；
• 更轻 - 更简单的结构，但缺乏一点组织；

And finally, in a book (http://shop.oreilly.com/product/0636920025344.do) suggests this structure:

最后，在一本书（http://shop.oreilly.com/product/0636920025344.do）中提出了这种结构：

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

回答by Daniel Chernenkov

More example from my project architecture you can see here:

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

├── 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

Basically, the logical app separated to DB and APP folders inside the SRC dir.

基本上，逻辑应用程序分离到 SRC 目录内的 DB 和 APP 文件夹。

回答by Manohar Reddy Poreddy

This is indirect answer, on the folder structure itself, very related.

这是间接答案，与文件夹结构本身非常相关。

A few years ago I had same question, took a folder structure but had to do a lot directory moving later on, because the folder was meant for a different purpose than that I have read on internet, that is, what a particular folder does has different meanings for different people on some folders.

几年前我有同样的问题，采用了文件夹结构，但后来不得不移动很多目录，因为该文件夹的目的与我在互联网上阅读的目的不同，也就是说，特定文件夹具有什么功能不同的人在某些文件夹上有不同的含义。

Now, having done multiple projects, in addition to explanation in all other answers, on the folder structure itself, I would strongly suggest to follow the structure of Node.js itself, which can be seen at: https://github.com/nodejs/node. It has great detail on all, say linters and others, what file and folder structure they have and where. Some folders have a README that explains what is in that folder.

现在，做了多个项目，除了所有其他答案中的解释，关于文件夹结构本身，我强烈建议遵循 Node.js 本身的结构，可以在以下位置看到：https: //github.com/节点/节点。它非常详细地介绍了所有内容，例如 linters 和其他人，他们拥有什么文件和文件夹结构以及在哪里。某些文件夹有一个 README，解释了该文件夹中的内容。

Starting in above structure is good because some day a new requirement comes in and but you will have a scope to improve as it is already followed by Node.js itself which is maintained over many years now.

从上面的结构开始是好的，因为总有一天会出现新的需求，但是您将有改进的余地，因为 Node.js 本身已经遵循了它，并且已经维护了很多年。

Hope this helps.

希望这可以帮助。

回答by thisismydesign

It's important to note that there's no consensus on what's the best approach and related frameworks in general do not enforce nor reward certain structures.

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

I find this to be a frustrating and huge overhead but equally important. It is sort of a downplayed version (but IMO more important) of the style guide issue. I like to point this out because the answer is the same: it doesn't matter what structure you use as long as it's well defined and coherent.

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

So I'd propose to look for a comprehensive guide that you like and make it clear that the project is based on this.

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

It's not easy, especially if you're new to this! Expect to spend hours researching. You'll find most guides recommending an MVC-like structure. While several years ago that might have been a solid choice, nowadays that's not necessarily the case. For example here's another approach.

这并不容易，特别是如果你是新手！预计花费数小时进行研究。您会发现大多数指南都推荐了类似 MVC 的结构。虽然几年前这可能是一个可靠的选择，但现在情况并非如此。例如，这是另一种方法。

回答by maxpaj

Assuming we are talking about web applications and building APIs:

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

One approach is to categorize files by feature, much like what a micro service architecture would look like. The biggest win in my opinion is that it is super easy to see which files relate to a feature of the application.

一种方法是按功能对文件进行分类，就像微服务架构的样子。在我看来，最大的好处是可以非常容易地查看哪些文件与应用程序的功能相关。

The best way to illustrate is through an example:

最好的说明方法是通过一个例子：

---

---

We are developing a library application. In the first version of the application, a user can:

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

• Search for books and see metadata of books
• Search for authors and see their books

• 搜索图书并查看图书的元数据
• 搜索作者并查看他们的书籍

In a second version, users can also:

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

• Create an account and log in
• Loan/borrow books

• 创建一个帐户并登录
• 借书/借书

In a third version, users can also:

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

• Save a list of books they want to read/mark favorites

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

---

---

First we have the following structure:

首先我们有以下结构：

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

We then add on the user and loan features:

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

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

And then the favorites functionality:

然后是收藏夹功能：

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

For any new developer that gets handed the task to add on that the books search should also return information if any book have been marked as favorite, it's really easy to see where in the code he/she should look.

对于任何接受添加任务的新开发人员来说，如果有任何书籍被标记为最喜欢的，书籍搜索也应该返回信息，很容易看出他/她应该在代码中查看的位置。

Then when the product owner sweeps in and exclaims that the favorites feature should be removed completely, it's easy to remove it.

然后当产品负责人冲进来并大声说应该完全删除收藏夹功能时，删除它很容易。