Extract JS specifics from library about purescript-spec

[owickstrom]

Cool! Ping me if there's anything you need help/feedback on.

[owickstrom]

Thanks! Would be very cool to have it running on purerl. I have almost zero experience with Erlang, but if you (and/or others) can do the heavy lifting, then sure!

So, purescript-js-timers could be removed as in #62, that seems all right. And you did the -ansi conversion as well. Are there other problematic ones? I see the purerl organization has a bunch of common libraries ported.

I'll try building and running your PRs!

[joneshf]

There is dateNow: https://github.com/owickstrom/purescript-spec/blob/557bec79c7d88bfd24764e5b6ab3ba2fc5c6e87b/src/Test/Spec/Runner.js#L6-L8. That could be replaced with https://pursuit.purescript.org/packages/purescript-now/3.0.0/docs/Control.Monad.Eff.Now#v:now

There are two spots that still use process:

• Test.Spec.Runner.exit: https://github.com/owickstrom/purescript-spec/blob/557bec79c7d88bfd24764e5b6ab3ba2fc5c6e87b/src/Test/Spec/Runner.js?utf8=%E2%9C%93#L10-L24
• Test.Spec.Console.write: https://github.com/owickstrom/purescript-spec/blob/557bec79c7d88bfd24764e5b6ab3ba2fc5c6e87b/src/Test/Spec/Console.js?utf8=%E2%9C%93#L17-L26

The write one feels like it could be replaced with Console.log, but it might take changing how write is used.

The exit one is a bigger problem. If it was just node that was the thing, I'd suggest having a library for dealing with process stuff and letting that be FFI'd in each backend. But phantom doesn't require an entirely new backend to compile it, so it's harder to suggest that. Although, if it were a thing, this function (in a completely different library) could go away as well: https://pursuit.purescript.org/packages/purescript-test-unit/13.0.0/docs/Test.Unit.Main#v:exit

I don't know that splitting this library into the plain PS stuff and the JS FFI'd stuff is a good idea either. Seems like purerl should just maintain a fork at that point.

So I'm leaning toward:

• Submitting a PR to use purescript-now
• Maintaining a fork of this repo for the purerl process stuff.

[owickstrom]

OK, not that much at least.

It seems these are so small and few, and they aren't changing much, so may the third alternative be that we add the .erl FFI modules directly in this repository? I could give you push access so that you could maintain the Erlang stuff here, if you'd like?

[joneshf]

That's definitely an option. I would only feel comfortable doing that if the travis stuff could be integrated as well. I guess that means we'd have to have binaries for purerl ready to go (we should have that anyway). I don't know how much an increase on build times that would make either. Are you okay with the build also doing Erlang stuff?

[owickstrom]

@joneshf Agreed, a Travis build would be important. I think if we use a build matrix we could run them in parallel, and keep the time down. It would probably increase the complexity of the build configuration, but I'm all right with that.

[owickstrom]

Do you have such a build set up for any other purerl projects?

[joneshf]

I don't, I should try to throw one together though.

[safareli]

As an update in case someone want's to pick this up, this are all FFI files at the moment in v4.0.0-rc1:

https://github.com/purescript-spec/purescript-spec/blob/v4.0.0-rc1/src/Test/Spec/Assertions/String.js
https://github.com/purescript-spec/purescript-spec/blob/v4.0.0-rc1/src/Test/Spec/Runner.js
https://github.com/purescript-spec/purescript-spec/blob/v4.0.0-rc1/src/Test/Spec/Console.js