这可能有点复杂，但我会尽我所能。我有一系列API模块，我正在使用Browserify，其中一些也调用其他模块。它们几乎交织在一起，这将使更新变得困难。
例如，假设我有五个模块：A，B，C，D和E. B和C需要A，C，D和E需要B.如果我需要制作一些对A进行更改的更新，我可以对其进行版本控制，但之后我需要更新B和C中的require语句。由于B现在使用不同版本的A，我也需要版本B，这意味着更改C，D和E中的require语句。因此，一个模块中的单个更改意味着我必须还原其他所有内容。
我应该注意到，主要原因是我必须保留旧版本。这些是小型微型网站，一个网站可能使用A-E构建，而下一个网站可能使用A' - E'构建，但我仍然需要能够独立构建两个网站。即使对A'的更改可能不会对它所暴露的API产生影响，但我不希望必须返回并重新测试每个单个文件修改所构建的每个项目。
我考虑过可能需要单独的每个项目文件，然后需要该项目的所有版本模块，但这是循环依赖。
如果重要，我正在使用Gulp和Browserify来构建最终的JS文件。
答案 0 :(得分：0)
我找到了可以解决问题的方法：aliasify
我将我的require语句更改为require('Api/ModuleA')，然后在aliasify配置中将Api/ModuleA映射到./libs/Api/ModuleA-1.0，并且每次需要模块A时它都会获取我想要的版本。
答案 1 :(得分：0)
我使用了类似于Java类路径的机制。我创建了一个自定义模块解析器，并为单独的项目使用单独的模块根。 Ther也是常见文件的文件夹。模块解析器首先针对项目文件夹中的模块进行搜索，如果未在公共文件夹中搜索到该模块。这样，您就可以为特定项目提供模块A的专门实现。不确定它是否适合您的情况。这就像aliasify一样，配置的差异由文件系统文件夹而不是配置文件支持。
A是一个只有少数依赖项的模块，并被许多模块引用。他们通常把这种模块称为“成熟”模式。这些成熟的模块应该经过充分测试，并且公共接口不应经常更改，因为每个相关模块都需要更新。因此，您可能会尝试在不破坏api的情况下进行更改，可能会创建一个具有版本化名称的新模块，以及使用新模块提供旧API的模块的包装器。新组件可以使用新模块，旧组件不受影响。
出于某种原因，他们使用多个数字来对软件进行版本控制。在最简单的情况下，有两个数字：主要版本和次要版本。次要版本可以随每个版本而变化，主要版本在公共API变化时会增加。只有在主要版本发生变化时才需要更新依赖于此组件的所有组件。 （当然有时候在一个次要版本的实现中存在一些错误，这些错误打破了一些依赖组件，但这不是通常的情况）。如果您更改A的公开API，则需要更改B和C，但不能更改其他人。A会有重大版本更改，B和C会有一个未成年人。其余的保持不变。这需要一个更复杂的模块解析器，它可以通过主要版本解析最新的模块。但那就是npm无论如何都会做的。