grunt-template-jasmine-istanbul icon indicating copy to clipboard operation
grunt-template-jasmine-istanbul copied to clipboard

Support Headless Chrome / Puppeteer

Open jabbany opened this issue 6 years ago • 8 comments

grunt-contrib-jasmine moved to headless chrome in v2.0 but this template seems to assume phantomjs which breaks when compiling the spec runner. Any way this could be updated to work on headless chrome? (and work with the new grunt-contrib-jasmine)

jabbany avatar Jun 16 '18 04:06 jabbany

Should be doable, only needs to adapt the way messages are sent back from the browser to the template. Also needs to check for possible changes how templates operate in jasmine v2.0 https://github.com/gruntjs/grunt-contrib-jasmine/wiki/Jasmine-Templates

maenu avatar Jun 16 '18 19:06 maenu

So as far as I can tell, grunt-contrib-jasmine no longer exposes the browser instance in the task object (in this case "page" for Puppeteer). Not sure if this is intentionally by design, but I can't find a way to hook new messages without changing their interface.

The way they bind messages is by just calling global functions bound to the window PuppeteerReporter.js

  const sendMessage = (type, param) => {
    window[type] && window[type](param);
  };

  const reporter = {
    jasmineStarted: function() {
      sendMessage('jasmine.jasmineStarted');
    }
    // ... Omitted
  }

and then binding to those functions when the page is set up jasmine.js

await page.exposeFunction('jasmine.jasmineStarted', function() {
    // ... Omitted
});

However, the template stuff happens before that in buildSpecrunner at which point the page doesn't exist yet.

The way I see how this could work somewhat neatly under the new framework would be something where they expose an additional listener that they also bind to, like jasmine.templateMessage and the reporters in the templates would just send messages to this endpoint. grunt-contrib-jasmine could then just forward the messages back to the templates (with another interface that allows this to be hooked up). But this would require changes on the grunt-contrib-jasmine side.

As it is structured right now, I don't see a clear way to get the __coverage__ string out from the puppeteer instance.

jabbany avatar Jun 18 '18 22:06 jabbany

Right, there is no page or anything in the task (https://github.com/gruntjs/grunt-contrib-jasmine/blob/a71cc54b6c60d275799436d02989167cf50ca1c0/tasks/lib/jasmine.js#L129). Maybe we can glue something together by setting the __coverage__ variable somewhere in a custom boot.js, then read it from a standard event in the reporter.js.

maenu avatar Jun 19 '18 17:06 maenu

Wouldn't boot.js just be another script loaded in the Puppeteer sandbox? We could control the jasmine instance in the sandbox, but it would still be hard to send that out to the grunt side (and in turn write to disk).

The handlers for all the standard events in the reporter just print stuff out (they don't really allow for hooks...) and the scripts in the page can't write anything to disk (including boot.js since it affects jasmine in the sandbox and not the grunt outside).

I think ideally we would want __coverage__ in jasmine.jasmineDone, close to somewhere like here, but idk how that would work without editing the grunt side code.

jabbany avatar Jun 19 '18 20:06 jabbany

If this has no side effects, I think modifying how the jasmine plugin works seems normal. It might allow other integrations as well.

Our failure to expose the page was not intentional, merely a regression of not fully understanding the scope of grunt-contrib-jasmine's ecosystem.

steveoh avatar Oct 19 '18 01:10 steveoh

Is there a solution or a workaround for this problem? Or how did you guys resolve the coverage of your code?

quater111 avatar Apr 12 '19 12:04 quater111

The current solution, unfortunately, is to use an older version of grunt-contrib-jasmine back from the days when it still used PhantomJS. Of course that means you get all the issues with running unmaintained code.

I never got around to actually making a patch for both projects to make things work harmoniously but maybe one of these days...

A more "future proof" solution may be to move to whatever new build and CI system that's popular these days. I have a hunch that not many people are interested in running jasmine+istanbul on grunt anymore...

jabbany avatar Apr 13 '19 03:04 jabbany

Hi, when is this PR going to merge? Also Is there any other solution to achieve the coverage with grunt-contrib-jasmine?

vatsala-glory avatar Jun 19 '19 07:06 vatsala-glory