如何使用NodeJS来组织构build，服务器，客户端和共享的JavaScript代码

在服务器上使用NodeJS的一个很大的好处是可以在服务器和客户端之间共享代码（例如inputvalidation）。 现在我实际上正在使用NodeJS开发一个难题，我发现确定每个代码体执行的责任和上下文。 下面我将列举一些我曾经遇到过的困难，希望能够对我可能会忽视的公约或指导方面有所启发，从而有助于提升这些问题。

构build时代码

为遵循基本文档而使用Gulp，Grunt或者vanilla NPM的项目构build时间代码通常非常容易。 大多数较小的项目都倾向于将所有的代码保存在一个单独的文件中，而文件往往被命名为gulpfile.js这样的传统名称，但是更大的项目我已经看到这些脚本开始被分割出来。 我已经看到一些情况下，吞噬文件被拆分成多个文件，并放置在一个单独的目录下。 更糟的是，我发现gulpfile.js文件甚至没有被命名为这样的情况，导致新开发人员四处寻找gulp文件的位置，一旦findgulp命令，总是必须运行具体的– -gulpfile选项。

运行时服务器端代码

基本节点应用程序的入口点似乎只需要在运行节点命令时指定特定的JavaScript文件（例如， node script.js ）。 对于Web服务器应用程序（例如使用Express的应用程序），我注意到按照惯例，入口点文件通常称为server.js，通常可以在应用程序的根目录中find。 但是，在其他一些情况下，比如在开发环境中运行Web服务器时，我看到吞噬任务承担了启动Node的责任。 在这些情况下，似乎有多种方法来包含入口点，但我发现的一个例子是启动webpack编译器，然后是入口点脚本的require语句。 在这种设置中，弄清楚如何结合正常的指导来完成典型的节点debugging命令是非常重要的。 除了应用程序的入口之外，NodeJS / Express应用程序的目录结构似乎没有任何一般指导，它们将服务器端特定的代码保留在位置上，以帮助查找它并使其与构build时间和客户端代码。

如果服务器端代码既用于提供静态内容，服务器端生成的视图（如使用MVC），也用于向客户端提供API，则服务器端故事变得更加复杂侧。 我的偏好是将API从应用程序项目中分离出来，但是我从其他人那里得到的感觉是，如果我认为这是一个合理的分离关注，那么就会有一种过度复杂的感觉。

运行时客户端代码

由于客户端代码可能经常有基于请求的第一页的各种入口点，这可能是棘手的。 但是由于URL的普遍透明性，以及它们在典型情况下如何映射资源，以及debugging工具在现代浏览器中的function如何强大，所以在脚本的后续工作中不会太麻烦。 对于客户端代码来说，困难在于典型的构build过程，而这些过程通常最终会复制文件并将其放置在不同名称的结构中。 一个例子是一个项目有一个名为src或js的文件夹，这个文件夹将客户端和服务器端代码混合在一起，除了只有一部分文件被包含在一个构build任务中，这个任务转换并经常连接文件和将它们放在分发文件夹中。 这些分发文件夹的常见名称是dist ， public ， www和wwwroot 。 通常情况下，如果不是这些目录总是在项目的根目录下，那么至less可以在不必询问构build脚本的情况下轻松定位。

我的希望是，对于如何把所有这些都集中在一个统一的指导下，或许是一个权威的来源，主要是指导像我这样的人可能想要从右脚开始。 作为一个副作用，即使是一个松散的标准，也可以参考某种标准，也可以减less一个团队在开始时要发明和讨论的样板量。 在上面列出的每个上下文中，显然会有一些技术特定的约定，例如在客户端用于AngularJS，Meteor或ReactJS的约定。 我正在寻找的约定更具体到分离端到端JavaScript应用程序中的主要高级上下文，其中语言和平台不再成为区分每种语言和平台的明显方式。

Answer 1

构build时代码

恕我直言，如果你有这么多的构build时代码，它不仅仅是说1000行，并且需要超过一小撮文件，一些事情已经脱离了轨道。 要么你不知道如何充分利用现有的npm包，或者你不知道如何重构通用代码并发布为独立的npm包。 如果您觉得需要关于项目构build时代码的指导，因为它太庞大复杂了，我的build议是模块化并分解成单独的项目 – 每个项目独立发布到npm。 也只是检查你的整体方法。 你在做什么，这是如此的习惯，需要这么多的机器？

运行时服务器端代码

请参阅ExpressJS的其他答案如何构build应用程序？

一般情况下，我宁愿看到客户端代码和服务器端代码要么完全独立的npm包（单独的git repos，单独发布的package.json文件）（如果它们足够大）或以其他方式混合在同一模块中并分组通过耦合（所有与包括前后端代码在内的function相关的代码），尤其是如果您的代码库有大量代码在两种环境中都能正常工作。

我有一个名为mjournal的开源的全栈节点/ JS应用程序，它使浏览器代码和节点代码保持一致。 你可以看一下，看看它是否合乎逻辑，容易理解代码的存在。 这绝不是一个受欢迎的方法，所以很多人会不喜欢它，但是我个人感觉很好，因为我已经把“团结一致”作为一个普遍的原则。

在这种设置中，弄清楚如何结合正常的指导来完成典型的节点debugging命令是非常重要的

是的，这是无稽之谈。 你的应用程序应该从npm start或类似node server.js东西npm start 。 精心devise混淆新开发人员的吞咽/咕噜声是不必要的复杂性，你应该消除。

在服务器端代码用于提供静态内容的情况下，服务器端的故事变得更加复杂

根据我的经验，提供静态内容的代码可以降至5行或更less，所以没什么大不了的。 如果你有一个非微观的代码处理静态内容，再一些事情已经走出了轨道。

运行时客户端代码

我的希望是，对于如何把所有这些都集中在一个统一的指导下，或许是一个权威的来源，主要是指导像我这样的人可能想要从右脚开始。

节点社区中有一些人采用了Ruby on Rails，EmberJS和其他一些大型项目中的“约定configuration”方法。 如果您喜欢这种方法，请查看使用它的工具，如SailsJS，EmberJS，Yeoman生成器等。

但一般来说，寻找一个“标准”并不是node.js / javascript / web社区的滚动方式。 小npm包。 由于小型文件被迫变为显而易见的布局。 由于前端工具链非常复杂，所以我觉得很沮丧，但最终还是因为浏览器中的JavaScript花费了太多的时间来创build一个合理的模块系统。 在未来的几年里，ES6模块是官方的规范，事情可能会开始标准化，但是由于CommonJS已经编写了很多的代码，并且像RequireJS / AMD这样的可怕前兆，我们将在可预见的未来处理这些代码。