purescript-spec/purescript-spec

Extract JS specifics from library

joneshf opened this issue · 9 comments

joneshf commented

This library is wonderful. I'd like to start using it with purerl. But the problem is, it has dependencies on specifics of JavaScript. There are still a couple of FFI modules here, and there's a dependency on purescript-js-timers. Are you interested in making this library able to be used by different backends? I don't want to suggest that you should maintain different backends though. That's kind of a big ask from me.

I have some ideas how this could be separated out, but I don't want you to have to maintain multiple libraries or have to jump through hoops to get things working. Assuming you're interested in allowing different backends, do you have any thoughts on how you'd like to make that possible?

owickstrom commented

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!

  • 👍1
joneshf commented

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:

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 commented

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 commented

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 commented

@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 commented

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

joneshf commented

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

owickstrom commented

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

  • ❤️2