我一直认为在服务器上使用 NodeJS 的一大好处是可以在服务器端和客户端之间共享一些代码（例如输入验证）。既然我实际上是在使用 NodeJS 进行开发，我发现的一个困难是确定执行每个代码主体的职责和上下文。下面我将列出我遇到的一些困难，希望对我可能忽略的有助于提升这些问题的约定或指导有所启发。
构建时代码
以遵循基本文档的方式使用 Gulp、Grunt 或 vanilla NPM 的项目的构建时间代码通常很容易遵循。大多数较小的项目倾向于将所有代码保存在一个文件中，并且该文件往往被命名为 gulpfile.js 之类的常规名称，但是对于较大的项目，我已经看到这些脚本开始被拆分。我见过一些情况，其中 gulp 文件被拆分为多个文件并放在单独的目录下。更糟糕的是，我发现 gulpfile.js 文件甚至没有被命名为这样的情况，这导致新开发人员四处寻找 gulpfile 所在的位置，一旦找到，gulp 命令总是必须使用特定的- -gulpfile选项。
运行时服务器端代码
基本节点应用程序的入口点似乎只需要在运行节点命令时指出一个特定的 JavaScript 文件（例如node script.js）。对于 Web 服务器应用程序，例如使用Express的应用程序，我注意到按照惯例，入口点文件通常称为 server.js，通常可以在应用程序的根目录中找到。然而，在其他一些情况下，例如在开发人员环境中运行 Web 服务器时，我看到 gulp 任务承担了启动 Node.js 的责任。在这些情况下，似乎有多种方法可以包含入口点，但我发现的一个示例是启动 webpack 编译器，然后是require入口点脚本的语句。在这种类型的设置中，弄清楚如何合并有关如何完成典型节点调试命令的常规指导并非易事。除了应用程序的入口点之外，似乎没有任何关于 NodeJS/Express 应用程序目录结构的一般指导，将服务器端特定代码保留在其位置以帮助定位它并将其与构建时分开，并且客户端代码。
如果服务器端代码用于提供静态内容、服务器端生成的视图（例如使用 MVC）以及为客户端提供 API，服务器端的故事会变得更加复杂边。我的偏好是将 API 从应用程序项目中分离出来，但我从其他人那里得到的感觉是这样做涉及到一种过于复杂的感觉，我认为这是一种合理的关注点分离。
运行时客户端代码
由于客户端代码通常可以根据请求的第一页有各种入口点，这可能会很棘手。然而，由于 URL 的一般透明度以及它们如何映射到典型情况下的资源以及调试工具在现代浏览器中变得多么强大，因此遵循脚本并没有太大的麻烦。相反，客户端代码的困难更多的是典型的构建过程，这些过程通常最终复制文件并将它们以不同的名称放入类似生产的结构中。例如，一个项目有一个名为src或js的文件夹它将客户端和服务器端代码混合在一起，除了只有一部分文件碰巧包含在构建任务中，该构建任务转换并经常连接文件并将它们放置在分发文件夹中。我见过的这些分发文件夹的常用名称是dist、public、www和wwwroot。通常（如果不总是）这些目录位于项目的根目录下，这至少使它更容易定位，而无需询问构建脚本。
我希望有一些关于如何以理智的方式将所有这些放在一起的一般性指导，也许是由权威来源提供的，主要是为了给像我这样可能想要从正确开始的人提供指导。作为一个副作用，也许能够参考某种标准，即使它是一个松散的标准，也可以减少团队在开始时必须发明和讨论的样板数量。在上面列出的每个上下文中，显然会有一些特定于技术的约定，例如客户端的 AngularJS、Meteor 或 ReactJS 遵循的约定。我正在寻找的约定更具体地用于分离端到端 JavaScript 应用程序中的主要高级上下文，其中语言和平台不再成为区分两者的明显方式。