关于带有作用域的npm模块的回归分析

Question

在1.10.x中，我对npm-deps的解析存在回归问题，这涉及到{{material-components-web}}。对于子依赖，它无法正确解析模块路径。当我require eg. {{@material/snackbar}}时，它将失败，错误如下：{{未捕获错误：模块$$material$base$component的nameToPath未定义}}。

重复步骤


yarn add "@cljs-oss/module-deps" "@material/snackbar"

cat <<EOF > deps.edn
{:deps {org.clojure/clojurescript {:mvn/version "1.10.145"}}}
EOF

clj -m cljs.main -d out -e "(require '[\"@material/snackbar\"])"


在1.9.946中，解析正常工作

Answer 1

评论由：dnolen发表

这个工单还需要更多信息。在此报告中，首先进行git bisect是一个很好的第一步。然后有人需要确定这是否是由于ClojureScript或Google Closure造成的。如果是后者，我们就无能为力了。

Answer 2

评论由：rarous发表

我甚至在1.10.63上也能重现这个回归，这样就可以缩小范围。我将准备向后兼容的重现和二分搜索。

Answer 3

评论由：rarous发表

通过二分搜索，发现是在#CLJS-2389（GCC更新）中引入的。

Answer 4

评论由：rarous发表

重现代码

Answer 5

评论由：rarous发表

当使用 head -2 out/node_modules/@material/snackbar/index.js 查看结束时以 {{goog.require("module$$material$base$index");}} 结尾，即为已损坏的情况。

Answer 6

评论由：dnolen发表

我能够重现并看到依赖索引文件 cljs_deps.js 看起来不对劲，所以它不工作并不奇怪。

Answer 7

评论由：dnolen发表

进一步挖掘，这可能是Closure的问题，我们需要等待上游修复。

Answer 8

评论由：dnolen发表

这是一个Closure Compiler的问题。我们需要提交一个补丁，然后为下一个Closure版本做必要的更改。此更改 https://github.com/swannodette/closure-compiler/commit/58012d3f1068aa588a47dc34ec6f39413aa59e62 解决了我模块名称的问题。

Answer 9

评论由：rarous发表

太好了，谢谢David。

Answer 10

评论由：dnolen发表

PR Closure Compiler https://github.com/google/closure-compiler/pull/2847

Answer 11

评论由：dnolen发表

能否在这张工单中添加一个非平凡的语句，该语句应在require之后生效？

Answer 12

评论由：dnolen发表

我想通了如何测试这个 - 事实上，它确实在master和我的Closure Compiler PR之后得到了解决。

Answer 13

评论由：rarous发表

抱歉我之前没有回复，我昨天参加了Code Retreat。这是一个DOM组件，所以非平凡示例需要在修改后的browser REPL中运行{{index.html}}。我想，如果发出的{{goog.require}}是正确的，那么其他一切都将正常工作。非常感谢修复。希望你的GCC PR能尽快被接受。{{1.10}}看起来非常稳定且快速。

Answer 14

评论由：dnolen发表

Closure Compiler PR现在有一个测试用例。在它被审查之后可能需要做一些小的调整，但希望这个修复可以在五月份的最新版本中包含。

Answer 15

评论者：tkjone

看起来谷歌 Closure 的 PR 已经被审核过了 https://github.com/google/closure-compiler/pull/2847