scala-js | Scala.js , the Scala to JavaScript compiler | Compiler library

Exporting objects/classes/functions as top level exports put them in Javascript global scope.

The errors you see are "IR checking errors". They mean that there are inconsistencies in the .sjsir files that are produced by the compiler. By default, they are only checked for fullOpt tasks, which is why you have not seen them before. However, that does not mean the IR is any more valid for fastOpt (it's the same IR!), so the error was always there (latent), but only surfaces now. Having IR checking errors means that the optimizer, or simply the JavaScript code generator, can produce nonsensical results.

(IR checking errors are also similar to VerifyErrors on the JVM.

Broadly speaking, there are 3 sources of IR checking errors:

• Using binary incompatible versions of transitive libraries can cause IR checking errors in some rare cases, even when no linking error arises.
• Bugs in the Scala.js core toolchain (compiler, linker)
• A particular known (and somewhat intentional) unsoundness issue in the Scala.js type system: js.Dynamic <: scala.Dynamic causes unsoundness in the IR.

What you are experiencing is the latter issue. It is quite rare. Basically, it happens if you assign (through = or passing a function argument, etc.) a value of type js.Dynamic to a value of type scala.Dynamic. For example:

@sjrd was correct, it was an old version of node.

I ran into one problem. In the course of trying to solve that, I read JavaScript Environments where it says to install nvm and then

The only thing that appears wrong with your example is how you pass data to the config: List is a Scala type that is opaque (i.e. meaningless) to JavaScript code. Instead, you need to use js.Array:

The manual to read when it comes to the DOM is mostly MDN web docs, scala-js-dom is only a very thin interface to it, with almost all methods being the same and returning the same types.

You are using the getElementById method which returns a generic Element type that does not have a value property because not all elements in the DOM have such a property. And scala-js-dom defines getElementById in the same way.

So essentially, you haven't proved to the compiler that the element you've selected is of a kind that has a value property, such as a HTMLInputElement or HTMLTextAreaElement. You will generally not be able to prove such things when using Javascript's native methods to query the DOM, because they are designed for dynamic Javascript, not for type safe access.

You can build your own helpers for this, such as:

By default, scalajs-bundler uses the "Application" bundling mode, which can throw away top-level exports. As the cookbook explains, when using @JSExportTopLevel, you need to the use the "LibraryAndApplication" bundling mode, using

The way you defined ButtonProps, with @js.native @JSGlobal, is telling Scala.js that it should not define ButtonProps itself, and that instead it should get ButtonProps from the JavaScript global scope. This only makes sense if some JavaScript code (e.g., in a library) actually defines that class.

If you meant to define ButtongProps yourself in the Scala.js code, then you should remove @js.native @JSGlobal and only keep

As the release notes of Scala.js 1.0.0 explain, you have to make sure to use scalaJSLinkerConfig instead of, among others, scalaJSModuleKind. In this case you will need

Exporting under a namespace was deprecated in Scala.js 0.6.26 and eventually removed in 1.x because such exports do not correspond to anything in terms of ECMAScript module exports. The compiler had to jump through non-standard hoops to make them appear to work.

As the release notes of 0.6.26, linked above, explain, the replacement is to explicitly construct a JS object that will hold those namespaces and the values to export. In your case: