Sébastien Doeraene

It says [here](https://github.com/scala-js/scala-js-fake-insecure-java-securerandom#usage-from-a-library): > ## Usage from a library > > **Never, ever depend on `scalajs-fake-insecure-securerandom` from library code!** > > If you do, you will expose your users to...

> What we can (and probably should) do is to publish a security advisory on scalajs-fake-insecure-securerandom to make it as likely as possible that scanners pick it up. I've been...

> I think the popularity of the JSDOM env for testing, which doesn't support WebCrypto, throws a wrench in this. Maybe that's the technical problem that needs to be solved....

Perhaps the best question to ask is: what directed you to the `fake-insecure` version instead of the actual secure version https://github.com/scala-js/scala-js-java-securerandom ?

> Reversi diff: https://gist.github.com/gzm0/a76d1307ee3b6d1404435f6f1523936c That's more remarkable than I thought. 😮

There's no technical issue with named imports besides the fact that it's difficult to emit them in our compiler in a way that fits incremental linking. We'll eventually do it,...

I'd rather we used refined `$i` end fields so that they also include the top-level identifier. Then they can be shared across all classes that import that field, and we...

Thanks for opening the issue. Could you also post here what happens when adding `@JSExport` directly on `object innerObj`, because that would be the root cause. `@JSExportAll` is merely a...

As a workaround, it's possible to export a getter for the object instead: ```scala class ClassWithInnerObj { val x = 1 @JSExport def innerObj: innerObjInternal.type = innerObjInternal object innerObjInternal extends...

Where can we see the result?