Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
If the codebase refers to an `@JSImport` entity, such as @js.native @jsimport("foo.js", "Bar") class Bar extends js.Object the codebase must be linked with `CommonJSModule` (or, in the future, other `ModuleKind`s supporting modules). Linking without module support causes a linking error. This causes facades for JS libraries supporting both module-style and script-style to be faced with an early choice: * either support linking with modules and use `@JSImport`, or * support linking without module support, and use `@JSGlobal` with whatever global names the JS library uses. It is however impossible to write a facade library that supports both use cases for their end users. This commit addresses this issue by adding an optional "global fallback" to `@JSImport`. We can now define a facade as follows: @js.native @jsimport("foo.js", "Bar", globalFallback = "Foo.Bar") class Bar extends js.Object That facade will successfully link both with and without module support. With module support, it links as if declared like in the first snippet. Without module support, it links as if declared as @js.native @jsglobal("Foo.Bar") class Bar extends js.Object Using this global fallback, a facade library can cater both for users who want to take advantages of modules, and users who want to stick to the script style. --- Implementation-wise, this is quite easy to implement. We simply add a new `JSNativeLoadSpec.ImportWithGlobalFallback`. It wraps both a `JSNativeLoadSpec.Import` and `Global`. That JS native load spec goes through the entire pipeline and reaches the emitter as is. The emitter decides which one to use depending on the `moduleKind`.
- Loading branch information