Node.js项目的文件夹结构

我注意到Node.js项目经常包含这样的文件夹:

/libs， /vendor， /support， /spec， /tests

这到底是什么意思呢?它们之间有什么不同，我应该在哪里包含引用的代码?

293696 次浏览
小开
最佳答案

关于你提到的文件夹:

  • /libs通常用于自定义classes/functions/modules
  • /vendor或/support包含第三方库(作为git添加) 使用git作为源代码控制时的子模块)
  • /spec包含BDD测试的规范。
  • /tests包含应用程序的单元测试(使用测试 框架,看到 李在这里) < / >

注意:/vendor和/support都已弃用，因为NPM引入了干净的包管理。建议使用NPM和包来处理所有第三方依赖关系。json文件

当构建一个相当大的应用程序时，我建议使用以下额外的文件夹(特别是如果你使用某种MVC- / orm框架，如表达或猫鼬):

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

    我已经习惯了用这种方式组织我的项目，我认为它效果很好。

    基于coffeescript的Express应用程序更新(使用connect-assets):

    • /app包含编译后的JavaScript
    • /assets/包含所有需要编译的客户端资产
      • /assets/js包含您的客户端CoffeeScript文件
      • /assets/css包含你所有的LESS/Stylus样式表
        • 李< / ul > < / >
      • /public/(js|css|img)包含不被任何编译器处理的静态文件
      • /src包含所有服务器端特定的CoffeeScript文件
      • /test包含所有单元测试脚本(使用您选择的测试框架实现)
      • /views包含你所有的表达视图(无论是jade, ejs或任何其他模板引擎)
小开
在GitHub上有一个讨论，因为一个类似的问题: https://gist.github.com/1398757 < / p >

你可以使用其他项目进行指导，在GitHub中搜索:

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

小开

这是间接的回答，就文件夹结构本身而言，关系很大。

几年前，我也有同样的问题，采取了一个文件夹结构，但后来不得不做了很多目录移动，因为文件夹的目的与我在互联网上读到的不同，也就是说，一个特定的文件夹对不同的人在一些文件夹上有不同的意义。

现在，已经做了多个项目，除了在所有其他答案中解释，关于文件夹结构本身，我强烈建议遵循Node.js本身的结构，可以在:https://github.com/nodejs/node中看到。它提供了所有文件的详细信息，比如linter和其他文件，它们有什么文件和文件夹结构以及在哪里。有些文件夹有一个README，解释文件夹中有什么。

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

小开

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

我发现这是一个令人沮丧和巨大的开销，但同样重要。它是风格指南的一种低调版本(但在我看来更重要)。我喜欢指出这一点，因为答案是相同的:你使用什么结构并不重要，只要它是明确的和连贯的。

所以我建议你找一份你喜欢的全面指南，并明确说明这个项目是基于这个指南的。

这并不容易，尤其是对新手来说!准备好花几个小时研究。您会发现大多数指南都推荐类似mvc的结构。虽然几年前这可能是一个可靠的选择，但现在情况未必如此。例如这是另一种方法。

小开

假设我们谈论的是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
└─ ...

对于任何新开发人员来说，如果有任何书籍被标记为收藏，那么图书搜索也应该返回信息，这很容易看出他/她应该在代码的哪里查找。

然后，当产品负责人突然出现并惊呼应该完全删除收藏夹功能时，就很容易删除它了。

小开

只需从GitHub克隆回购

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

这是一个node.js express.js项目的基本结构 已经设置MongoDB作为数据库，hbs作为视图引擎，nodemon也， 所以你可以很容易地设置node js express project

步骤1:下载或克隆
的repo 步骤2:打开任何代码编辑器
步骤3:在
文件夹路径下打开终端 第四步:在终端npm start
中运行注释 步骤5:开始编码


提交答案