尝试使用elm-install
将github存储库用作依赖项时出现此错误3: dup //what are we duplicating here exactly?
4: invokespecial #3 //what does the #3 in operand stand for?
invokevirtual VS invokespecial //what difference there is between these opcodes?
这究竟意味着什么？
答案 0 :(得分：3)
（此答案由@linas在Elm Slack频道提供）
这意味着Elm无法在您的包的上下文中编译该包的源代码。
想象一下，我制作了一个包my-fancy-package，并且依赖于包foo/bar。所以在my-fancy-package/elm-package.json中，我可以拥有像"foo/bar": "1.0.0 <= v < 2.0.0"这样的依赖关系。现在，在我开发foo/bar期间，my-fancy-package的最新版本可能是1.5.0。在版本1.5.0中，添加了一个新功能，它完全符合我在my-fancy-package中的需要，因此我开始使用该功能。核心问题是，目前没有自动测试程序包实际上与所有允许的依赖项版本一起使用的方法。所以现在my-fancy-package说foo/bar和1.0.0之间的任何版本都取决于2.0.0，而实际上，它确实需要至少为1.5.0，因为我和＃39; m使用该软件包中的函数。
现在，假设您正在开发一个应用程序，并且您在版本foo/bar上使用1.2.3。根据{{1}}的semver范围，这意味着您应该可以使用它，但如果您真的尝试使用它，则会收到此错误：my-fancy-package表示它兼容使用my-fancy-package，但确实需要foo/bar@1.2.3。
错误消息之所以简单地说＆＃34;它无法编译＆＃34;是因为所有发布的包都是在发布之前编译的。程序包在某些上下文中无法编译的最常见原因是它的依赖关系不准确＆＃34;它们会让太多东西通过。
如果1.5.0和来自github的软件包很难说 - 它实际上可能是破解包。
这个错误的另一个常见原因是一个相当愚蠢的 - 中缀运算符的冲突定义。中缀操作的关联性和优先级只能定义为＆＃34;全局＆＃34;，所以如果有2个包定义相同的中缀操作符，则可能会成为问题