此问题请求在使用通过合格引用传递性加载的 Closure 库时，抑制分析器警告。
{code:title=co.edn}
{:libs ["libs/mylib.js"]}
{code:title=libs/mylib.js}
goog.provide('my_lib.core')
my_lib.core = {
add: function(x, y) { return x + y; }
}
{code:title=src/foo/core.cljs}
(ns foo.core
(:require my-lib.core
clojure.set))
以下是一个演示此概念的示例
$ clj -m cljs.main -co co.edn -re node -r
ClojureScript 1.10.339
cljs.user=> (clojure.set/intersection #{1 2 3} #{2 4 5})
WARNING: 在行 1 使用未声明的 Var clojure.set/intersection <cljs repl>
...
cljs.user=> (require 'foo.core)
nil
cljs.user=> (clojure.set/intersection #{1 2 3} #{2 4 5})
#{2}
cljs.user=> (clojure.set/intersection)
WARNING: clojure.set/intersection 的参数数量错误 (0) 在行 1 <cljs repl>
cljs.user=> (my-lib.core/add 2 3)
WARNING: 无法找到命名空间: my-lib.core，无法找到 my_lib/core.cljs、my_lib/core.cljc 或提供 "my-lib.core" 的 JavaScript 源代码 (请检查使用破折号命名空间的命名空间是否在 ClojureScript 文件名中使用下划线) 在行 1 <cljs repl>
WARNING: 在行 1 使用未声明的 Var my-lib.core/add <cljs repl>
5
cljs.user=> (in-ns 'foo.core)
nil
foo.core=> (my-lib.core/add 2 3)
5
在上面的示例中，您可以看到，当通过合格符号使用传递性加载的 ClojureScript 命名空间（在此例中为 {{clojure.set}}）时，分析器可正常工作。
这种特性显然目前不适用于 Closure 库，因此在这个例子中，仅仅为了避免分析器警告，需要修订（正确运行的）源代码（并且源代码需要意识到命名空间是由 Closure 库而不是 ClojureScript 命名空间实现的）。
提高此增强功能的论点是，它带来了一致性，并使在有效场景中清洁使用 Closure 库成为可能，这些场景中使用了传递性依赖关系。（通常不直接在给定的命名空间中指示依赖关系是不好的，但一个可以说是令人满意的用法是当您正在使用一个命名空间，该命名空间公开的宏会扩展以使用该命名空间传递性加载的代码。这可能发生在通过 {{:libs}} 定义库的宏或甚至是通过 Closure 库的库中。)
