Question

请考虑将具有本机依赖关系的Scala.js库实现为纯JavaScript CommonJS模块。

该库包含JavaScript依赖项的外观。正如所料，外观包括许多代码，如：

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

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

为什么js.native不与JSExport兼容？如何在外墙上添加对@JSExport的支持？

现在有可用的解决方法吗？

Answer 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中捆绑任意数量的导入。

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

1 个答案: