针对范围 npm 模块的回归

Question

在 1.10.x 的 npm-deps 解析中，我遇到了 {{material-components-web}} 的回归。对于子依赖项，它无法正确解析模块路径。当 me.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 中复现此回归，以缩小范围。我将准备向后兼容的复现和 bisect。

Answer 3

由：rarous 添加评论

Bisected it and it was introduced in #CLJS-2389 (GCC update)

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 添加评论

抱歉之前没有回应，我昨天参加了代码 retreat。这是一个 DOM 组件，因此需要修改 {{index.html}} 并在浏览器 REPL 中运行非平凡的示例。我认为，如果发出的 {{goog.require}} 正确，其他一切都将正常工作。非常感谢你的修复。我希望你的 GCC PR 能尽快被接受。{{1.10}} 看起来非常稳定且快速。

Answer 14

由：dnolen 添加评论

Closure Compiler PR 现在有一个测试案例。在被审查后可能需要进行一些小的调整，但希望这个修复可以最早在五月份的版本中实现。

Answer 15

评论者：tkjone

PR 到 google closure 已被审查 https://github.com/google/closure-compiler/pull/2847