我注意到Node.js项目通常包含以下文件夹：
/ libs，/ vendor，/ support，/ spec，/ tests
这究竟是什么意思？它们之间有什么不同，我应该在哪里包含引用的代码？
答案 0 :(得分：421)
关于您提到的文件夹：
/libs 通常用于自定义classes/functions/modules /vendor 或 /support 包含第三方库（添加为git）
使用git作为源代码控制时的子模块）/spec 包含BDD测试的规范。/tests 包含应用程序的单元测试（使用测试
框架，见
here） 注意：由于NPM引入了干净的包管理，因此不推荐使用/vendor和/support。建议使用NPM和package.json文件处理所有第三方依赖项
在构建相当大的应用程序时，我建议使用以下附加文件夹（特别是如果您使用某种MVC- / ORM-Framework，如express或mongoose）：
/models 包含您的所有ORM模型（在mongoose中称为Schemas）/views 包含您的视图模板（使用快递支持的任何模板语言）/public 包含所有静态内容（图片，样式表，客户端JavaScript）
/assets/images 包含图片文件/assets/pdf 包含静态pdf文件/css 包含样式表（或由css引擎编译输出）/js 包含客户端JavaScript /controllers 包含所有快速路由，以应用程序的模块/区域分隔（注意：使用express的引导功能时，此文件夹名为 {{1 }} ）我习惯于以这种方式组织我的项目，我觉得它很好用。
基于CoffeeScript的Express应用程序更新（使用connect-assets）：
/routes 包含已编译的JavaScript /app 包含需要编译的所有客户端资产
/assets/ 包含您的客户端CoffeeScript文件/assets/js 包含您的所有LESS / Stylus样式表/assets/css 包含未由任何编译器处理的静态文件/public/(js|css|img) 包含所有服务器端特定的CoffeeScript文件/src 包含所有单元测试脚本（使用您选择的测试框架实现）/test 包含您的所有快递视图（无论是jade，ejs还是其他任何模板引擎）答案 1 :(得分：46)
有一个关于GitHub的讨论，因为有一个与此类似的问题： https://gist.github.com/1398757
您可以使用其他项目获取指导，在GitHub中搜索：
最后，在一本书（http://shop.oreilly.com/product/0636920025344.do）中建议了这个结构：
答案 2 :(得分：12)
从我的项目架构中可以看到更多示例：
├── 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文件夹。
答案 3 :(得分：3)
假设我们正在谈论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
对于接受任务的新开发人员，如果书籍被标记为收藏，书籍搜索还应该返回信息，这很容易看出他/她应该在代码中查找的位置。
然后，当产品所有者进入并宣称应该完全删除“收藏夹”功能时，很容易将其删除。
答案 4 :(得分：1)
这是文件夹结构本身的间接答案，非常相关。
几年前我有同样的问题，拿了一个文件夹结构，但后来不得不做很多目录移动，因为该文件夹的目的不同于我在互联网上阅读的目的，也就是说，特别是文件夹对某些文件夹中的不同人有不同的含义。
现在，除了在所有其他答案中的解释之外，在文件夹结构本身上完成了多个项目，我强烈建议遵循Node.js本身的结构，可以在https://github.com/nodejs/node看到。它有很多详细信息，比如linters和其他人，他们有什么文件和文件夹结构以及在哪里。某些文件夹有一个README，用于解释该文件夹中的内容。
从上面的结构开始是好的，因为有一天会出现一个新的需求，但是你会有一个改进的范围，因为Node.js本身已经存在多年，现在已经维护了。
希望这有帮助。
答案 5 :(得分：1)
重要的是要注意，对于什么是最佳方法和相关框架一般不执行或奖励某些结构，没有达成共识。
我发现这是一个令人沮丧和巨大的开销，但同样重要。它是style guide issue的一种低调版本（但更重要的是IMO）。我想指出这一点，因为答案是一样的：只要它的定义和连贯性，你使用什么结构并不重要。
因此，我建议您寻找您喜欢的综合指南，并明确指出该项目是基于此。
这并不容易，特别是如果你是新手！期待花几个小时研究。您会发现大多数指南推荐类似MVC的结构。虽然几年前可能是一个可靠的选择，但现在情况并非如此。例如here's another approach。