blocks|key|2262563|text|关于您提到的文件夹：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2262564|/libs通常用于自定义classes/functions/modules|unordered-list-item|offset|length|style|BOLD|CODE|2262565|/vendor或/support包含第三方库(在使用git作为源代码管理时添加为git子模块)。|2262566|/spec包含BDD测试的规范。|2262567|/tests包含应用程序的单元测试(使用测试框架，请参见这里)。|2262568|注意:由于NPM引入了一个干净的包管理，所以/vendor和/support都被废弃了。建议使用NPM和package.json文件处理所有第三方依赖项。|2262569|在构建一个相当大的应用程序时，我建议使用以下其他文件夹(特别是当您使用某种MVC-+/ORM-框架(如快递或猫鼬)时)：|2262570|/models包含所有ORM模型(在猫鼬中称为Schemas+)|2262571|/views包含视图-模板(使用快递支持的任何模板语言)|2262572|/public包含所有静态内容(图像、样式表、客户端JavaScript)+。|2262573|/assets/images包含图像文件|2262574|/assets/pdf包含静态pdf文件|2262575|/css包含样式表(或由css引擎编译的输出)|2262576|/js包含客户端JavaScript|2262577|2262578|​|2262579|/controllers包含您的所有快速路由，由应用程序的模块/区域分隔(注意:当使用express的引导功能时，此文件夹称为/routes)。|2262580|我习惯了用这种方式组织我的项目，我认为效果很好。|2262581|基于CoffeeScript的应用程序更新(使用)|2262582|/app包含已编译的JavaScript|2262583|/assets/包含所有需要编译的客户端资产。|2262584|/assets/js包含客户端CoffeeScript文件。|2262585|/assets/css包含了所有的/Stylus样式表|2262586|2262587|2262588|/public/(js%7Ccss%7Cimg)包含未由任何编译器处理的静态文件。|2262589|/src包含所有服务器端特定的CoffeeScript文件。|2262590|/test包含所有单元测试脚本(使用您选择的测试框架实现)|2262591|/views包含您所有的表示视图(无论是玉、ejs还是任何其他模板引擎)。|2262592|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/joyent/node/wiki/modules#wiki-testing|1|https://github.com/visionmedia/express/tree/master|2|http://mongoosejs.com/^0|0|0|5|0|5|C|P|0|0|7|8|8|0|7|8|8|0|0|5|0|5|0|0|6|0|6|S|2|0|0|M|7|U|8|0|1F|2|1|1I|2|2|0|0|7|0|7|N|7|0|0|6|0|6|0|0|7|0|7|1|0|E|0|E|1|0|B|0|B|1|0|4|0|4|1|0|3|0|3|1|0|0|0|C|1R|7|0|C|1R|7|0|0|F|9|0|0|4|0|4|0|0|8|0|8|1|0|A|0|A|1|0|B|0|B|1|0|0|0|K|0|K|0|0|4|0|4|0|0|5|0|5|0|0|6|0|6|0^^$0|@$1|2|3|4|5|6|7|2A|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|2B|8|@$E|2C|F|2D|G|H]|$E|2E|F|2F|G|I]|$E|2G|F|2H|G|I]]|9|@]|A|$]]|$1|J|3|K|5|D|7|2I|8|@$E|2J|F|2K|G|H]|$E|2L|F|2M|G|H]|$E|2N|F|2O|G|I]|$E|2P|F|2Q|G|I]]|9|@]|A|$]]|$1|L|3|M|5|D|7|2R|8|@$E|2S|F|2T|G|H]|$E|2U|F|2V|G|I]]|9|@]|A|$]]|$1|N|3|O|5|D|7|2W|8|@$E|2X|F|2Y|G|H]|$E|2Z|F|30|G|I]]|9|@$E|31|F|32|1|33]]|A|$]]|$1|P|3|Q|5|6|7|34|8|@$E|35|F|36|G|I]|$E|37|F|38|G|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|39|8|@]|9|@$E|3A|F|3B|1|3C]|$E|3D|F|3E|1|3F]]|A|$]]|$1|T|3|U|5|D|7|3G|8|@$E|3H|F|3I|G|H]|$E|3J|F|3K|G|I]|$E|3L|F|3M|G|I]]|9|@]|A|$]]|$1|V|3|W|5|D|7|3N|8|@$E|3O|F|3P|G|H]|$E|3Q|F|3R|G|I]]|9|@]|A|$]]|$1|X|3|Y|5|D|7|3S|8|@$E|3T|F|3U|G|H]|$E|3V|F|3W|G|I]]|9|@]|A|$]]|$1|Z|3|10|5|D|7|3X|8|@$E|3Y|F|3Z|G|H]|$E|40|F|41|G|I]]|9|@]|A|$]]|$1|11|3|12|5|D|7|42|8|@$E|43|F|44|G|H]|$E|45|F|46|G|I]]|9|@]|A|$]]|$1|13|3|14|5|D|7|47|8|@$E|48|F|49|G|H]|$E|4A|F|4B|G|I]]|9|@]|A|$]]|$1|15|3|16|5|D|7|4C|8|@$E|4D|F|4E|G|H]|$E|4F|F|4G|G|I]]|9|@]|A|$]]|$1|17|3|-4|5|6|7|4H|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|4I|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|D|7|4J|8|@$E|4K|F|4L|G|H]|$E|4M|F|4N|G|H]|$E|4O|F|4P|G|I]|$E|4Q|F|4R|G|I]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|4S|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|4T|8|@$E|4U|F|4V|G|H]]|9|@]|A|$]]|$1|1G|3|1H|5|D|7|4W|8|@$E|4X|F|4Y|G|H]|$E|4Z|F|50|G|I]]|9|@]|A|$]]|$1|1I|3|1J|5|D|7|51|8|@$E|52|F|53|G|H]|$E|54|F|55|G|I]]|9|@]|A|$]]|$1|1K|3|1L|5|D|7|56|8|@$E|57|F|58|G|H]|$E|59|F|5A|G|I]]|9|@]|A|$]]|$1|1M|3|1N|5|D|7|5B|8|@$E|5C|F|5D|G|H]|$E|5E|F|5F|G|I]]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|5G|8|@]|9|@]|A|$]]|$1|1P|3|19|5|6|7|5H|8|@]|9|@]|A|$]]|$1|1Q|3|1R|5|D|7|5I|8|@$E|5J|F|5K|G|H]|$E|5L|F|5M|G|I]]|9|@]|A|$]]|$1|1S|3|1T|5|D|7|5N|8|@$E|5O|F|5P|G|H]|$E|5Q|F|5R|G|I]]|9|@]|A|$]]|$1|1U|3|1V|5|D|7|5S|8|@$E|5T|F|5U|G|H]|$E|5V|F|5W|G|I]]|9|@]|A|$]]|$1|1W|3|1X|5|D|7|5X|8|@$E|5Y|F|5Z|G|H]|$E|60|F|61|G|I]]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|62|8|@]|9|@]|A|$]]]|1Z|$20|$5|21|22|23|A|$24|25]]|26|$5|21|22|23|A|$24|27]]|28|$5|21|22|23|A|$24|29]]]]

Concerning the folders you mentioned:

<ul>
<li><code>/libs</code> is usually used for custom <code>classes/functions/modules</code></li>
<li><code>/vendor</code> or <code>/support</code> contains 3rd party libraries (added as git
sub-module when using git as source control)</li>
<li><code>/spec</code> contains specifications for BDD tests.</li>
<li><code>/tests</code> contains the unit-tests for an application (using a testing
framework, see
<a href="https://github.com/joyent/node/wiki/modules#wiki-testing" rel="noreferrer">here</a>)</li>
</ul>

NOTE: both <code>/vendor</code> and <code>/support</code> are deprecated since NPM introduced a clean package management. It's recommended to handle all 3rd-party dependencies using NPM and a package.json file

When building a rather large application, I recommend the following additional folders (especially if you are using some kind of MVC- / ORM-Framework like <a href="https://github.com/visionmedia/express/tree/master" rel="noreferrer">express</a> or <a href="http://mongoosejs.com/" rel="noreferrer">mongoose</a>):

<ul>
<li><code>/models</code> contains all your ORM models (called <code>Schemas</code> in mongoose)</li>
<li><code>/views</code> contains your view-templates (using any templating language supported in express)</li>
<li><code>/public</code> contains all static content (images, style-sheets, client-side JavaScript)

<ul>
<li><code>/assets/images</code> contains image files</li>
<li><code>/assets/pdf</code> contains static pdf files</li>
<li><code>/css</code> contains style sheets (or compiled output by a css engine)</li>
<li><code>/js</code> contains client side JavaScript</li>
</ul></li>
<li><code>/controllers</code> contain all your express routes, separated by module/area of your application (note: when using the bootstrapping functionality of express, this folder is called <code>/routes</code>)</li>
</ul>

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

Update for CoffeeScript-based Express applications (using <a href="https://github.com/adunkman/connect-assets" rel="noreferrer">connect-assets</a>):

<ul>
<li><code>/app</code> contains your compiled JavaScript</li>
<li><code>/assets/</code> contains all client-side assets that require compilation

<ul>
<li><code>/assets/js</code> contains your client-side CoffeeScript files</li>
<li><code>/assets/css</code> contains all your LESS/Stylus style-sheets</li>
</ul></li>
<li><code>/public/(js|css|img)</code> contains your static files that are not handled by any compilers</li>
<li><code>/src</code> contains all your server-side specific CoffeeScript files</li>
<li><code>/test</code> contains all unit testing scripts (implemented using a testing-framework of your choice)</li>
<li><code>/views</code> contains all your express views (be it jade, ejs or any other templating engine)</li>
</ul>

blocks|key|2621642|text|有关于GitHub的讨论，因为有一个类似于这个问题的问题：https://gist.github.com/1398757|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2621643|您可以使用其他项目作为指导，在GitHub中搜索：|2621644|ThreeNodes.js+-在我看来，似乎有一个特定的结构，不适合每一个项目；|unordered-list-item|2621645|更轻-一个更简单的结构，但缺乏一点组织；|2621646|最后，在一本书(http://shop.oreilly.com/product/0636920025344.do)中提出了这种结构：|2621647|├──+index.html
├──+js/
│+++├──+main.js
│+++├──+models/
│+++├──+views/
│+++├──+collections/
│+++├──+templates/
│+++└──+libs/
│+++++++├──+backbone/
│+++++++├──+underscore/
│+++++++└──+...
├──+css/
└──+...|code-block|syntax|javascript|2621648|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/1398757|1|http://shop.oreilly.com/product/0636920025344.do^0|T|V|0|0|0|0|0|8|1C|1|0|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|16|8|@]|9|@]|C|$]]|$1|I|3|J|5|H|7|17|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|18|8|@]|9|@$A|19|B|1A|1|1B]]|C|$]]|$1|M|3|N|5|O|7|1C|8|@]|9|@]|C|$P|Q]]|$1|R|3|-4|5|6|7|1D|8|@]|9|@]|C|$]]]|S|$T|$5|U|V|W|C|$X|Y]]|Z|$5|U|V|W|C|$X|10]]]]

There is a discussion on GitHub because of a question similar to this one:
<a href="https://gist.github.com/1398757" rel="noreferrer">https://gist.github.com/1398757</a>

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

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

And finally, in a book (<a href="http://shop.oreilly.com/product/0636920025344.do" rel="noreferrer">http://shop.oreilly.com/product/0636920025344.do</a>) suggests this structure:

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

blocks|key|2262610|text|从我的项目体系结构中可以看到更多的示例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2262611|├──+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|code-block|syntax|javascript|2262612|基本上，逻辑应用程序分离到SRC+dir中的DB和app文件夹。|2262613|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

More example from my project architecture you can see here:

<pre><code>├── Dockerfile
├── README.md
├── config
│   └── production.json
├── package.json
├── schema
│   ├── create-db.sh
│   ├── db.sql
├── scripts
│   └── deploy-production.sh 
├── src
│   ├── app -&gt; Containes API routes
│   ├── db -&gt; DB Models (ORM)
│   └── server.js -&gt; the Server initlializer.
└── test
</code></pre>

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

blocks|key|2262674|text|这是间接的回答，关于文件夹结构本身，非常相关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2262675|几年前，我有同样的问题，我采用了一个文件夹结构，但后来不得不做很多目录移动，因为这个文件夹的目的与我在互联网上看到的不同，也就是说，一个特定的文件夹对于某些文件夹上的不同的人有不同的含义。|2262676|现在，在完成了多个项目之后，除了在所有其他答案中解释了文件夹结构本身之外，我强烈建议遵循Node.js本身的结构，它可以在：https://github.com/nodejs/node上看到。它有非常详细的所有，如指针和其他人，文件和文件夹的结构，他们有和在哪里。有些文件夹有一个自述文件，它解释了该文件夹中的内容。|offset|length|2262677|从上面的结构开始是很好的，因为总有一天会有一个新的需求出现，但是您将有一个需要改进的空间，因为它已经被Node.js本身所遵循，这是经过多年维护的。|2262678|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/nodejs/node^0|0|0|1Q|U|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$F|U|G|V|1|W]]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

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: <a href="https://github.com/nodejs/node" rel="nofollow noreferrer">https://github.com/nodejs/node</a>. 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.
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.

blocks|key|1065242|text|需要注意的是，对于什么是最好的方法还没有达成共识，相关的框架一般不会强制执行或奖励某些结构。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1065243|我觉得这是一个令人沮丧和巨大的开销，但同样重要。这是一种淡化版(但更重要的是海事组织)的风格指南问题。我想指出这一点，因为答案是一样的：--不管您使用什么结构--只要它是定义良好和连贯的。|offset|length|style|BOLD|1065244|因此，我建议寻找一个您喜欢的全面指南，并明确指出，该项目是基于这一点。|1065245|这不容易，特别是如果你是新手！希望花上几个小时研究。您会发现大多数指南推荐类似MVC的结构。几年前，这可能是一个很好的选择，但现在情况不一定如此。例如，这是另一种方法。|1065246|entityMap|0|LINK|mutability|MUTABLE|url|https://www.codementor.io/mattgoldspink/nodejs-best-practices-du1086jja#5-use-a-style-guide|1|https://blog.risingstack.com/node-hero-node-js-project-structure-tutorial/^0|0|1W|P|18|6|0|0|0|24|7|1|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@$D|X|E|Y|F|G]]|9|@$D|Z|E|10|1|11]]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|L|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|M|$N|$5|O|P|Q|A|$R|S]]|T|$5|O|P|Q|A|$R|U]]]]

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 <a href="https://www.codementor.io/mattgoldspink/nodejs-best-practices-du1086jja#5-use-a-style-guide" rel="nofollow noreferrer">style guide issue</a>. 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.

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 <a href="https://blog.risingstack.com/node-hero-node-js-project-structure-tutorial/" rel="nofollow noreferrer">here's another approach</a>.

blocks|key|2621873|text|假设我们讨论的是web应用程序和构建API：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2621874|一种方法是通过特性对文件进行分类。为了说明：|2621875|我们正在开发一个库应用程序。在应用程序的第一个版本中，用户可以：|2621876|搜索书籍并查看书籍的元数据|unordered-list-item|2621877|寻找作者并看他们的书|2621878|在第二个版本中，用户还可以：|2621879|创建一个帐户并登录|2621880|贷款/借阅帐簿|2621881|在第三个版本中，用户还可以：|2621882|保存他们想要阅读的书籍列表/标记收藏夹|2621883|首先，我们有以下结构：|2621884|books
++└─+entities
++│+++└─+book.js
++│+++└─+author.js
++│
++└─+services
++│+++└─+booksService.js
++│+++└─+authorsService.js
++│
++└─+repositories
++│+++└─+booksRepository.js
++│+++└─+authorsRepository.js
++│
++└─+controllers
++│+++└─+booksController.js
++│+++└─+authorsController.js
++│
++└─+tests
++++++└─+...|code-block|syntax|javascript|2621885|然后，我们添加用户和贷款特性：|2621886|user
++└─+controllers
++└─+entities
++└─+services
++└─+...

loan
++└─+controllers
++└─+...|2621887|然后是收藏夹功能：|2621888|favorites
++└─+controllers
++└─+entities
++└─+...|2621889|对于任何新开发人员来说，如果任何一本书被标记为最受欢迎的书，那么就可以很容易地看到他/她应该查看的代码中的位置。|2621890|然后，当产品负责人大摇大摆地说，应该完全删除收藏夹功能时，很容易将其删除。|2621891|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1G|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1H|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1I|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|1J|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|1K|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1L|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|1M|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1N|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1P|8|@]|9|@]|A|$]]|$1|W|3|X|5|Y|7|1Q|8|@]|9|@]|A|$Z|10]]|$1|11|3|12|5|6|7|1R|8|@]|9|@]|A|$]]|$1|13|3|14|5|Y|7|1S|8|@]|9|@]|A|$Z|10]]|$1|15|3|16|5|6|7|1T|8|@]|9|@]|A|$]]|$1|17|3|18|5|Y|7|1U|8|@]|9|@]|A|$Z|10]]|$1|19|3|1A|5|6|7|1V|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|1W|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|1X|8|@]|9|@]|A|$]]]|1E|$]]

Assuming we are talking about web applications and building APIs:
One approach is to categorize files by feature. To illustrate:
<hr />
We are developing a library application. In the first version of the application, a user can:
<ul>
<li>Search for books and see metadata of books</li>
<li>Search for authors and see their books</li>
</ul>
In a second version, users can also:
<ul>
<li>Create an account and log in</li>
<li>Loan/borrow books</li>
</ul>
In a third version, users can also:
<ul>
<li>Save a list of books they want to read/mark favorites</li>
</ul>
<hr />
First we have the following structure:
<pre><code>books
 └─ entities
 │ └─ book.js
 │ └─ author.js
 │
 └─ services
 │ └─ booksService.js
 │ └─ authorsService.js
 │
 └─ repositories
 │ └─ booksRepository.js
 │ └─ authorsRepository.js
 │
 └─ controllers
 │ └─ booksController.js
 │ └─ authorsController.js
 │
 └─ tests
 └─ ...
</code></pre>
We then add on the user and loan features:
<pre><code>user
 └─ controllers
 └─ entities
 └─ services
 └─ ...

loan
 └─ controllers
 └─ ...
</code></pre>
And then the favorites functionality:
<pre><code>favorites
 └─ controllers
 └─ entities
 └─ ...
</code></pre>
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.

blocks|key|2621915|text|只需从GitHub克隆回购|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2621916|https://github.com/abhinavkallungal/Express-Folder-Structure|offset|length|2621917|这是一个node.js+express.js项目的基本结构，它已经设置了MongoDB作为数据库，hbs也作为视图引擎，nodemon，所以您可以轻松地设置节点js速递项目。|2621918|步骤1:下载或克隆回购|2621919|步骤2:在任何代码编辑器中打开|2621920|步骤3:在文件夹路径上打开终端|2621921|步骤4:在终端npm+start中运行注释|style|CODE|2621922|步骤5:开始编码|2621923|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1O|0|0|0|0|0|0|7|9|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@$D|12|E|13|1|14]]|A|$]]|$1|F|3|G|5|6|7|15|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|16|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|19|8|@$D|1A|E|1B|P|Q]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1C|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|C]]]]

Just clone the repo from GitHub
<a href="https://github.com/abhinavkallungal/Express-Folder-Structure" rel="nofollow noreferrer">https://github.com/abhinavkallungal/Express-Folder-Structure</a>
This is a basic structure of a node.js express.js project
with already setup MongoDB as database, hbs as view engine, nodemon also,
so you can easily set up node js express project
Step 1: download or clone the repo 
Step 2: Open in any code editor 
Step 3: Open the terminal on the folder path 
Step 4: run the comment in terminal <code>npm start</code> 
Step 5: start coding

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

<blockquote>
 /libs, /vendor, /support, /spec, /tests
</blockquote>

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

Folder structure for a Node.js project

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我注意到Node.js项目通常包括这样的文件夹：/libs，/vendor，/support，/spec，/tests这些到底是什么意思？它们之间有什么不同，我应该在哪里包含引用的代码？

问Node.js项目的文件夹结构
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Node.js项目的文件夹结构EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Node.js项目的文件夹结构
EN