【问题标题】：How to "publish" a private Typescript npm package in git?如何在 git 中“发布”私有 Typescript npm 包？
【发布时间】：2019-07-26 22:05:18
【问题描述】：

我认为这应该是一个标准问题，但我找不到任何答案...

我有两个打字稿项目 - LibraryA 和 WebserverB。它们是独立的项目，每个项目都有自己的 git 存储库。它们也是私人项目 - 我不希望它们公开。

显然，我想在 WebserverB 中使用 LibraryA。我认为正确的方法是通过 npm，因为它管理所有其他库。幸运的是 npm 在依赖项中支持 git URL，所以我可以直接将它指向 LibraryA 的存储库。

但是，该存储库不包含已编译的 Javascript 文件，仅包含 TypeScript 文件。我怎样才能使这项工作？或者在这种情况下正确的方法是什么？

【问题讨论】：

标签： git typescript npm publishing

【解决方案1】：

我猜你可以在库的package.json 中添加一个install 脚本来编译它。然后您只需将main 和types 指向输出文件。

【讨论】：

嗯.. 这是一种方式，但是这会将 TypeScript 从开发依赖项中带出并进入完全依赖项
没错，不过可能还有其他解决方案。

【解决方案2】：

如果您不想从 git 存储库中的源安装依赖项，这里有其他解决方案：

解决方案 #1 — 从本地文件夹安装依赖项

一个简单的解决方案是通过git clone 安装LibraryA 并构建它。然后，在WebserverB/，你可以做一个npm install ../path/to/local/LibraryA：

npm install :

将目录中的包安装为当前项目中的符号链接。它的依赖项将在链接之前安装。如果位于项目的根目录中，则其依赖项可能会像其他类型的依赖项一样被提升到顶层 node_modules。 (Source: NPM documentation)

解决方案 #2 — 安装私有 npm 代理注册表

您可以在您的服务器上安装私有 npm 代理注册表，例如 Verdaccio。然后，您将能够发布包含所有已编译文件的包。

解决方案 #3 — 支付 NPM 并发布私有包

您可以通过付费帐户在private repository 中发布一个真正的包（也包含已编译的文件）。

解决方案 #4 — 在您的 GitHub 存储库上发布（未测试）

NPM documentation 表示另一个选项：

npm install

获取 tarball url，然后安装它。为了区分此选项和其他选项，参数必须以“http://”或“https://”开头

然后，发布一个包，用于构建、压缩并将其作为new release 上传到您的私人 Github 存储库中。之后，应该可以使用个人访问令牌通过 URL 访问 tarball？

【讨论】：

等等，等等，等等。我想要从 git 存储库安装我的依赖项。我只是不知道如何正确地做到这一点。
@Vilx- 我刚刚有了一个想法。我编辑了答案以将其添加为解决方案 4。
我认为您不能将 npm 指向 GIT 存储库中的单个 tarball。它没有直接拼写出来，但它有点隐含在install documentation 中。但是，您可以使用 tarball 的纯 URL。或者，如果您已经在调用一个单独的 GIT 存储库，为什么不创建一个仅包含已构建包的存储库呢？无需压缩任何东西。然而这已经变得很奇怪了，所以一个更简单的方法是在你的原始源存储库中提交构建的 JS 文件并使用它。
这具有将源代码与编译的 JS 结果一起分发的副作用，但无论如何我们都在谈论私有包，所以这不应该成为问题。更好的是，它可以帮助调试。
@Vilx- 或者是在你的 Github repo 版本中上传的压缩包？（我编辑了解决方案 4）

【解决方案3】：

好的，我将用其他答案的摘要和一些额外的选项来回答我自己的问题。

经过一番思考，我意识到了这一点。问题是 - 谁以及何时运行 tsc 将 LibraryA 的 Typescript 编译为 Javascript？基本上只有几个选择：

LibraryA 的开发者运行它并发布编译结果（某处）；
LibraryA 以源代码形式发布，并且在将包安装到 WebserverB 时进行编译；
LibraryA 以源代码形式发布，构建 WebserverB 也会编译该库。

让我们详细了解一下。

1。发布编译结果

那么问题是 - 发布的结果存储在哪里？它必须在 NPM 可以访问它的地方。因此，再次只有几个选择：

npm 注册表（私有，如果你能负担得起，公共如果你同意的话）。缺点：嗯，你得付钱。
某个服务器上的 tarball，您可以在其中获取它的 URL。缺点：你必须得到一个服务器来托管这些。并照顾好上述服务器。
新的 GIT 存储库。未打包，因为 npm 无法从 git 存储库中解压缩。缺点：一个项目现在有两个存储库。
LibraryA 所在的同一 git 存储库。本质上，您不仅提交了 TypeScript 源文件，还提交了编译结果。缺点：提交编译工件是错误。您正在将源代码与编译结果一起发布。您不需要 WebserverB 中的那些。
LibraryA 所在的同一 git 存储库，但在一个单独的、断开连接的分支中。缺点：这会让人感到困惑。你见过多少个仓库有两个不连贯的主分支？

尽管有缺点，但它们都是可用的选项。

2。安装时编译

这里的主要缺点是这会立即对 WebserverB 上的 typescript 产生依赖。不仅是开发依赖，而且是完整的运行时依赖。这可能没问题，但它变得非常奇怪。您打算如何部署 WebserverB？这也会运行编译吗？我不认为这是要走的路。但这是可能的。详情请见H.B.'s answer。

3。与WebserverB一起编译

好吧，如果您只打算在打字稿项目中使用它，这可能没问题。我不确定是否要安装它。您需要修改 tsconfig.json 文件以在编译中包含 node_modules/LibraryA。这很奇怪。您的 IDE 会对此感到高兴吗？总而言之，这也不是一个好主意。感觉就像是在对抗/滥用系统，而且很少有好的结局。

最后，我想我会采用“提交编译的 JS”的方法。因为“just wrong”不是一个好的论据。而且由于它是一个私人项目，因此额外发布的资源也不是什么大问题。事实上，也许他们甚至会帮助调试。

【讨论】：