如何使用NodeJS组织构建、服务器、客户端和共享JavaScript代码

我一直认为在服务器上使用NodeJS的一大好处是在服务器和客户端之间共享代码位（例如输入验证）。现在我正在使用NodeJS进行开发，我发现的一个困难是确定执行每个代码体的责任和上下文。下面我将列出一些我曾经遇到的困难，希望能从我可能忽略的、有助于提升这些问题的惯例或指导中获得一些启示

---

构建时代码

对于以遵循基本文档的方式使用Gulp、Grunt或vanilla NPM的项目，构建时代码通常非常容易遵循。大多数较小的项目倾向于将所有代码保存在一个文件中，该文件倾向于使用传统名称命名，如gulpfile.js，但是对于较大的项目，我看到这些脚本开始被拆分。我见过一些将gulp文件拆分为多个文件并放在单独目录下的情况。更糟糕的是，我发现gulpfile.js文件甚至没有这样命名，这导致新开发人员四处寻找gulpfile的位置，一旦找到，gulp命令总是必须使用特定的--gulpfile选项运行

运行时服务器端代码

基本节点应用程序的入口点似乎只需要在运行node命令时指出特定的JavaScript文件（例如

node script.js

）。对于web服务器应用程序，例如使用的应用程序，我注意到按照惯例，入口点文件通常称为server.js，通常可以在应用程序的根目录中找到。然而，在其他一些情况下，例如在开发人员环境中运行web服务器时，我看到gulp任务承担了启动节点的责任。在这些情况下，似乎有多种方式包含入口点，但我发现的一个示例是启动webpack complier，然后启动入口点脚本的require语句。在这种类型的设置中，弄清楚如何结合关于如何完成典型命令的常规指导是非常重要的。除了应用程序的入口点之外，对于NodeJS/Express应用程序的目录结构似乎没有任何一般性的指导，这些应用程序将特定于服务器端的代码保留在适当的位置，以帮助定位它，并将其与构建时和客户端代码分开

当服务器端代码用于提供静态内容、服务器端生成的视图（如MVC）以及向客户端提供API时，服务器端的情况变得更加复杂。我倾向于将API从应用程序项目中分离出来，但我从其他人那里得到的感觉是，这样做有一种过度复杂的感觉，我认为这是一种合理的关注点分离

运行时客户端代码

由于客户端代码通常基于请求的第一个页面具有不同的入口点，因此这可能很棘手。然而，由于URL在典型情况下是如何映射到资源的，并且在现代浏览器中调试工具的功能是多么强大，因此遵循脚本并不太麻烦。客户端代码的难点在于典型的构建过程，这些过程通常会复制文件，并将它们以不同的名称放入类似于产品的结构中。例如，一个项目有一个名为src或js的文件夹，该文件夹混合保存客户端代码和服务器端代码，但只有一部分文件碰巧包含在生成任务中，该任务转换并经常连接文件，并将其放置在分发文件夹中。我看到的这些分发文件夹的常见名称是dist、public、www和wwwroot。通常（如果不是总是的话）这些目录位于项目的根目录，这至少使它更容易定位，而不必询问构建脚本

---

我希望有一些关于如何以理智的方式将所有这些结合在一起的一般性指导，也许是由权威人士提供的，主要是为像我这样可能希望从正确的角度出发的人提供指导。作为一个副作用，也许能够参考某种标准，即使它是一个松散的标准，也可以减少团队在开始时必须发明和讨论的样板文件的数量。在上面列出的每个上下文中，显然都会有一些特定于技术的约定，例如客户端上AngularJS、Meteor或ReactJS遵循的约定。我正在寻找的约定更具体地分离端到端JavaScript应用程序中的主要高层上下文，在这些应用程序中，语言和平台不再成为区分它们的明显方式。

构建时代码

如果你有太多的构建时代码，比如说超过1000行，并且需要的文件也不止一小部分，那么有些东西就出轨了。要么您不知道如何充分利用来自npm的现有包，要么您不知道如何重构通用代码并作为独立的npm包发布。如果您觉得需要关于项目构建时代码的指导，因为它是如此庞大和复杂，我的建议是将其模块化并拆分为单独的项目——每个项目都独立发布给npm。也只是检查一下你的整体方法。你在做什么，这样的习惯，需要这么多的机器

运行时服务器端代码

请看我对这个问题的另一个答案

一般来说，我更愿意看到客户端代码和服务器端代码完全分开的npm包（分开的git repos、分开的package.json文件，独立发布）（如果它们很大的话）