Jasmine unable to work with rails 6

[prakash03]

I do see some commits to master that are potential fixes to make jasmine work with rails 6 applications! I am just trying to know if there is a release planned anytime soon with these fixes. Please let me know if there is a release date that I should wait for!

Thanks!

[slackersoft]

Something still seems to be wrong with Jasmine's tests when running with Rails 6, so I'm not quite ready to drop a release. It looks like everything is working in the real world, but I'd like to see the tests going so we can catch any regressions that might occur in the future.

At the moment the specs seem to be failing only with RAILS_VERSION=rails6 with Puma failing to start up when running the specs. I'd be happy to review any pull requests or other help on figuring out how to resolve the specs.

[amilligan]

I've spent a fair bit of time on this, and I now have jasmine functioning nicely with webpacker in Rails 6. I've put the results in a new repository (https://github.com/buildgroundwork/jasmine-rails-webpacker) rather than submitting a PR, for reasons that will become clear.

I spent some time trying to wedge webpacker into the existing Jasmine gem, but the current state of affairs made that very difficult. Specifically, the jasmine gem currently tries to handle every possible environment in which it might run: Rails, Node, POJS, other things I'm probably forgetting. I decided early on to worry only about Rails with webpacker. So, to that end I made Rails a hard dependency for the gem and removed everything not Rails-related. That simplified things dramatically; if you take a look at the resulting code you'll find it is much simplified.

Incidentally, I have always believed that the jasmine gem should really be several target-specific gems, like RSpec has (e.g. rspec, rspec-core, rspec-rails, etc.; hence the name of the new repository). I honestly don't recall exactly why the decision was made not to do that; perhaps @infews or @ragaskar can chime in to remind me why they chose a single multi-purpose gem when we discussed it ten years ago. I'm happy to do some work in that direction if prevailing sentiment has shifted.

I chose to use yarn to install jasmine-core in the install process, which removes any dependence on the jasmine-core gem. Note that jasmine with webpack is a non-starter without the changes I made to the JS in https://github.com/jasmine/jasmine/pull/1766. I've been using yarn to install it directly in my projects from the https://github.com/buildgroundwork/jasmine repository, which works for the time being.

Installing Jasmine with this library adds a couple pack files, which are used in the test run, as well as a couple minor additions to the webpacker config. Your main application simply doesn't include the spec-specific packs, so outside of the test environment they just sit there unused. I removed every reference to the asset pipeline, so this should work in a pure webpack project.

I also removed the jasmine.yml file. All configuration can be done via the Jasmine.config call, which I moved to a Rails initializer, and by modifying the spec-specific packs directly. By default it will pick up any files in spec/javascript, but just as with anything else in webpack you can change that to your taste.

I have not updated the README in the repository to reflect these changes yet. Sorry about that, but getting it working, and using it to write some specs, was my first priority. I will update the documentation as soon as I can.

I set the version of this new library to 6.0.x to match the major version of Rails it's meant to work with. I haven't tested it with Rails 5 + webpacker.

I've also given the webpacker-friendly treatment (and then some) to https://github.com/jasmine/jasmine-ajax (at https://github.com/buildgroundwork/jasmine-ajax). Documentation there is also not yet up-to-date; stay tuned.

@slackersoft

[amilligan]

Documentation on https://github.com/buildgroundwork/jasmine-rails-webpacker is now up to date. Please open issues there if you find problems with it.

[prakash03]

Thanks for all the work done here to support rails 6!! @amilligan

I will get my application tested with the new repository you linked here and open issues if I am facing any!

I currently have my rails 6 app pointed to this repository's master branch and I am able to run jasmine tests just fine. We have only a small set of tests written in jasmine and they seem to be liking this so far. Could you tell me or point me in the right direction so that I understand the exact problem I would have if I continue using this repo's master?

FWIW, I would definitely give it a shot and update the gem dependency to the new repo you created! Hopefully this is going to see a release some time soon.

Again, appreciate all the help here!

[amilligan]

@prakash03 I wouldn't recommend using a Github repository directly in the long term. Currently you're using the master branch (because I haven't provided anything else yet), which will change as any commits are added to the repo. There's value in having clear releases with documented changes. There's also value in having a canonical repository for a library; if there are several forks of a given repo then it becomes impossible for anyone to resolve all of the changes pushed to each.

I'm hoping that Gregg (@slackersoft) or someone with his blessing will make a decision about what to do with all of this and whether they want to bring it under the official Jasmine umbrella. Alternately, they could use it as inspiration to fix the existing jasmine gem repository.

In short, I hope this repo lives a short, but useful, life. In the short term I should be a better open source citizen and provide a release tag so you're not floating on master. I'll do that ASAP.

I'm glad it's working for you.

[amilligan]

Incidentally, I believe a lot of the folks who maintain Jasmine have their hands full with unrelated issues at the moment, so patience is probably the word of the day for the foreseeable future.

[prakash03]

@amilligan I totally understand I'd run into issues as you add more commits to master and that stuff would break here when I continue to use master directly!! My question was more towards, what exactly is the problem jasmine is currently running into by supporting rails 6? This may be a really broad question so any little briefing should help me! Also, it would be great if you could provide a specific example of the type of test or the errors I would hit when running them in rails 6?

We are pretty much on the same page here!! Just like you said, I'd keep my eyes open for that one good release that solves all the problems!

[amilligan]

@prakash03 Sorry, I misunderstood your question.

Webpack appears to have a couple problems with the Jasmine gem in its current incarnation.

First, Jasmine is fairly fast and loose with global state, and Webpack aggressively prevents sharing state across modules. I discussed that in jasmine/jasmine#1766 as well as jasmine/jasmine-ajax#197.

Second, and more germane to this issue, is that the Jasmine gem is deeply integrated into the Rails asset pipeline. As it kind of had to be, when the asset pipeline was the only game in town. The gem essentially starts the server and for each request builds an HTML response, injecting all necessary JS files (jasmine JS, application JS, spec JS, etc.) into the template on the fly. Webpack obviously works completely differently, and it took replacing pretty much all of that HTML response generation, configuration, etc. to get Jasmine to play nicely with packs.

As it happens, the old approach uses a bunch of fairly mind-bending asset pipeline magic and custom Rack handlers. The webpack version is much simpler; it took just a bit of sleight of hand to make ActionView do most of the work.

[slackersoft]

I haven't really had a chance to look at some of the other work being done to help Jasmine work with Rails 6, but here are some thoughts...

I think the reason the Jasmine tooling was originally created with Ruby and Rails in mind is because that's the server-side language and libraries that the Pivots who built it were working with. Currently, the reason for the continued existence of this repository is to be able to handle javascript that is managed by the Rails asset pipeline.

As we released things like the Python egg, NPM package and the new Node.js-based Jasmine browser runner some of the general use-cases for the ruby gem have gone away (specifically the plain old JavaScript case). Additionally, the rest of the web developer tools standardizing on NPM packages makes having a seemingly random Ruby dependency to do some things with Jasmine harder to justify.

In the short-to-medium term, my plan is to shore-up and document how to use the browser runner with webpack and other bundling agents and make that the primary way that folks run their Jasmine tests in a real browser. Jasmine-Core is already using this library to run its own tests, but I don't think there is much other usage, so I'm not entirely sure what it's missing. The goal is to reduce the number of languages and packages needed in order to maintain and/or contribute to Jasmine. The basic vision is:

• Jasmine-core: Just the Jasmine library. Ideally, we'll get it to a point where it is requireable in a Node.js codebase, but global(-ish) as now in a browser where you don't want to pack it up.
• Jasmine-npm: The jasmine package on npm. Used to run pure Node.js tests and tests that you are comfortable running with JSDom or some other fake DOM.
• Jasmine-browser-runner: When you really want an actual browser. This handles starting a server, selenium (optional SauceLabs), and gathering results from your suite.

This plan should allow the gentle deprecation of Jasmine-Gem (this repo), Jasmine-Py, and gulp-jasmine-browser. Currently the only one of these three repos that does anything special is the asset pipeline handling here.

My original plan with node.js-based browser runner was to leave the actual serving of the html and assets plugable so that things like the Rails asset pipeline could be plugged in to serve the assets that would actually be used by application. With the move to Webpacker and the underlying Node.js based toolchain for bundling assets in Rails 6, this may eliminate the need to manage any Ruby code in the Jasmine codebases.

[stoivo]

I think we might be happier with createing a new gem jasmine-webpacker to work with webpacker and leave out support for webbacker here. Since I assume the sprocket way stil works with rails 6?

If we go with that we could try to make it so the gems can be installed in the same project.

[sgravrock]

First, the bad news: Rails 7 will default to something new rather than Webpacker or Sprockets. That news has dampened my already minimal enthusiasm for writing & maintaining code to support each of Rails's ways of packaging JS.

The good news: jasmine-browser-runner is far enough along that I'm comfortable recommending it, and it works with Webpacker without any need for Webpacker-specific code. (Also Sprockets, although the developer experience isn't quite as nice.) You can find some basic documentation about how to set it up with Rails at https://jasmine.github.io/setup/browser.html#use-with-rails.

We'll continue to maintain the jasmine gem for the near future but we have no plans to add Webpacker support now that jasmine-browser-runner has that covered.

@amilligan Thanks for your work on jasmine-rails-webpacker. Having working code on hand was a huge time-saver, even though I ended up going in a different direction.