在 Scala.js 外观中，为什么 @js.native 注释排除了 @JSExport 注释？

【问题标题】：In Scala.js facades, why does the @js.native annotation preclude the @JSExport one?在 Scala.js 外观中，为什么 @js.native 注释排除了 @JSExport 注释？
【发布时间】：2018-06-04 22:14:20
【问题描述】：

请考虑使用纯 JavaScript CommonJS 模块实现的原生依赖的 Scala.js 库。

该库包含 JavaScript 依赖项的外观。正如预期的那样，外观包含很多代码，例如：

@JSImport("com", "Foo") @js.native
class Foo extends js.Object { ... }

不幸的是，ScalaJS-Bundler 以一种将 Foo 隐藏在全局范围内的方式捆绑了它。显而易见的解决方法是将 @JSExport 注释添加到其他两个，但这会导致编译器错误。

为什么 js.native 不兼容 JSExport？在外观上添加对 @JSExport 的支持需要什么？

现在有解决办法吗？

【问题讨论】：

标签： scala.js scalajs-bundler

【解决方案1】：

顶级类和对象上的@JSExport 已弃用in Scala.js 0.6.15。你所追求的其实是@JSExportTopLevel。

@JSExportTopLevel 与@JSImport/@JSGlobal 不兼容没有根本原因。这不是因为以下 3 件事：

支持它意味着在整个编译器工具链中需要做更多的工作来支持它，
感觉像是一个罕见的用例，并且
还有另一种方法可以达到同样的效果。

实现结果的另一种方法是简单地导出一个val存储导入的结果，如下：

@js.native
@JSImport("com", "Foo")
class Foo extends js.Object { ... }

// 'private' not to pollute the Scala API with this object
private object Reexports {
  @JSExportTopLevel("Foo") // or another name
  val Foo = js.constructorOf[Foo]
}

如果您只重新导出一个这样的导入，那肯定会有点冗长，但您可以在唯一的object Reexports 中捆绑任意数量。

【讨论】：