'repo_name/package_name' 的 elm-package.json 约束可能让太多东西通过了

elm-package.json constraints of 'repo_name/package_name' are probably letting too much stuff through

我在使用 elm-install

尝试将 github 存储库用作依赖项时遇到此错误
Problem in dependency repo_name/package_name 1.0.0

The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.

这到底是什么意思?

(此回答由 Elm Slack 频道的@ilias 提供)

这意味着 Elm 无法在您的包的上下文中编译该包的源代码。

想象一下我正在制作一个包 my-fancy-package,并且我依赖于一个包 foo/bar。所以在 my-fancy-package/elm-package.json 中,我可以有一个像 "foo/bar": "1.0.0 <= v < 2.0.0" 这样的依赖项。现在,在我开发 my-fancy-package 时,foo/bar 的最新版本可能是 1.5.0。在版本 1.5.0 中,添加了一个新函数,它完全满足我在 my-fancy-package 中的需要,因此我开始使用该函数。核心问题是目前没有自动化的方法来测试一个包是否真的可以使用所有允许的依赖版本。所以现在 my-fancy-package 说它依赖于 1.0.02.0.0 之间的任何版本的 foo/bar,而实际上,它确实至少需要 1.5.0 因为我我正在使用该包中的一个函数。

现在,假设您正在开发一个应用程序,并且您使用的是 foo/bar 版本 1.2.3。根据 my-fancy-package 的 semver 范围,这意味着你应该能够使用它,但如果你真的尝试它,你会收到这个错误:my-fancy-package is stating it is compatible with foo/bar@1.2.3 而它确实需要 1.5.0.

错误信息没有简单的说"it failed to compile"的原因是因为所有发布的包都是在发布前编译的。包在某些上下文中无法编译的最常见原因是它的依赖项不是 "accurate":它们让太多东西通过了。

如果 elm-install 和来自 github 的包,则很难说 - 它实际上可能是损坏的包。

此错误的另一个常见原因是一个相当愚蠢的原因 - 中缀运算符的定义冲突。只能定义中缀运算符的关联性和优先级 "globally",因此如果有 2 个包定义了相同的中缀运算符,这可能会成为问题