And by working, I mean that I can pass the specs (added 1 more) and I don't get any deprecation warnings or uncaught errors in the Javascript console

Any reason for not targeting rspec 3.2?

@elia - No good reason. It's just the version I was using on a Ruby project. I could do the upgrade work to 3.2 for this PR. I wanted to get feedback before I went too far with this. The Rake task I setup to derive the requires file (rather than the old way of having to arrange it just right) hopefully will make it easier to stay current.

Don't bother, I checked out the branch and working on some cleanup in the util files, so I'll this branch along with those changes.

I'll close the other PR as I see it's included in this one.

Ok. In case its not obvious, the Rake task was designed to basically make
all of rspecs dynamic requires static but in a way that's easy to change.
Designed to be more of a developer tool than a CI driven thing.
On Jun 3, 2015 11:37 AM, "Elia Schito" notifications@github.com wrote:

Don't bother, I checked out the branch and working on some cleanup in the
util files, so I'll this branch along with those changes.

I'll close the other PR as I see it's included in this one.

—
Reply to this email directly or view it on GitHub
#19 (comment).

I took a look at RSpec 3.2 just to get an idea. Seems like the easiest way to get over the rubyfeatures/eval problem was to add an 'ignore' capability to the create_requires.rb script I worked on and then put a pre_require version of that in.

The harder problem I ran into was super() crashing in RSpec::Configuration

@elia I also did some work with formatters. Check out https://github.com/wied03/opal-rspec-formatter

I think it probably makes sense to keep this as a separate GEM. I monkey patch Opal::RSpec::RakeTask so that it has "2 mains", one to set the formatter and then whatever the Rake task (default opal-rspec, user, opal-rails) has specified. It's a little goofy, but I didn't want to have to do something special for opal-rails, etc. to work.

Thoughts?

Most of this was getting 'builder' to work, which I eventually did (that's another github repo - https://github.com/wied03/opal-builder). JUnit was the logical choice because most CI systems can read the results from that.

Thanks! Too bad I'm struggling to find the time to review and merge properly these PRs :)

@wied03 Hey, just saw these two pull requests (been away for a while, but getting back into opal work now!). What's the status with these? The rspec work was always tricky, so I'm glad you were able to make progress with them

@adambeynon , I think @elia was going to create an RSpec 3.1 branch and merge this PR into that. Then there would be a 'cleaner' baseline to evaluate the async PR and work on RSpec 3.2+

@adambeynon I started refactoring the files in the utils/ dir which was the only thing that I though needed a review. Can totally push the WIP somewhere if you want to continue from where I left.

Also I think it's notable that the RSpec guys were willing to have an opal-based online demo of RSpec once we updated to the latest release

@elia, @wied03 Ah awesome. Yeah, any code would be great. I don't mind putting the shift in to get it all working.

@elia I do recall that - would be quite nifty to have that. Worth the push to get the newest stuff working straight on opal. They might be willing to help out with some of our monkey patching (mutable string fixes etc).

@adambeynon yes, they seemed happy to help with mutable string stuff and compat in general, will push in a moment

@adambeynon here: https://github.com/opal/opal-rspec/tree/rspec-3-1-wip

@elia @adambeynon - Anything I can do to help move this along?