Version 1.0

[alexandru]

The version 1.0 for the Scala.js API.

• Imported the license, copying, contributing guidelines
• I've setup the built.sbt as best as I could, should be ready for publishing :-) but please check that I haven't missed anything
• The interfaces are translated with exact types. For example Publisher.subscribe does use-site variance because this interface is meant for cross-compiled projects and so the translation has to be exact
• I've converted JavaDoc to ScalaDoc as best as I could, but hope I haven't made any stupid typos

[alexandru]

Branch is this one: https://github.com/reactive-streams/reactive-streams-scalajs/tree/version-1

[ktoso]

This list is somewhat outdated now; shall I write up the changes needed or we leave as is? cc @viktorklang

[viktorklang]

Yep, that's pretty outdated, but I think it needs to be updated separately. I'll open an Issue to discuss that.

[ktoso]

As far as for an initial import LGTM.
A few open questions still, but we'll iron them out as we go I think

[viktorklang]

May I ask why this file was modified?

[alexandru]

I copied the LICENSE from the JVM project, because I saw a difference between LICENSE and COPYING and I also brought it COPYING. Not sure why, thought it makes sense to have it identical to the JVM project, but I'm not a lawyer.

I can revert this change if you want, no problem.

[viktorklang]

Makes total sense to have it be identical to the JVM project. I only wanted to know the rationale :)

[smaldini]

I'm not entirely sure we need a ScalaJS on reactive-streams org but I don't explicitly mind neither. So I guess I'm not really qualified to discuss about it 👍
For my own education, why is that hosted here and not on a Lightbend repository ? Is Scala JS somehow standard enough to appeal to the JS audience ? In others terms who are the target of that standard vs something more generic as plain JS or Typescript ?

[viktorklang]

@smaldini I guess it needs to be under the same organisation as the other reactive streams artifacts or otherwise it wouldn't be substitutable between compiling for jvm vs compiling for js. I think that's a good enough reason for a separate project but under the same umbrella, of course as long as it doesn't deviate from the RS APIs, spec and TCK.

Personally I'd love to see more action over here as well: https://github.com/reactive-streams/reactive-streams-js :)

[smaldini]

I understand, IMO the only point that could save us from repeat is a plain JS TCK. At least something to test all JS impls given the natively useless nature of types in JS (and for RS in general I'd argue its about the behavior, the types don't bring much). Would that work for ScalaJS as well ?

[smaldini]

That said somehow, seeing engineering practices in JS is not something I'm fighting off quite the contrary, I live in a perpetual JS dev trauma ever since I touched it.

[viktorklang]

@smaldini I think scalajs could use the -jvm TCK for the server side and if needed, the -js TCK (when available) to run on V8 etc.

(I did JavaScript before there were frameworks/libs) #jshipster :)

[andreaTP]

Right now JUnit support is built in in Scala.js and ScalaCheck support even asynchronous testing,
Writing it will not be that hard, but we firstly need to know the exact semantics that should be checked in a single threaded env.

Hope this could revamp the discussion and we can end up with a solution!

[alexandru]

Hi guys.

What would be needed to move this project forward. A TCK?

[viktorklang]

@alexandru A TCK would most definitely be helpful. :)