Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Headless Chrome / Puppeteer #63

Open
jabbany opened this issue Jun 16, 2018 · 8 comments
Open

Support Headless Chrome / Puppeteer #63

jabbany opened this issue Jun 16, 2018 · 8 comments

Comments

@jabbany
Copy link
Contributor

jabbany commented Jun 16, 2018

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)

@maenu
Copy link
Owner

maenu commented Jun 16, 2018

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

@jabbany
Copy link
Contributor Author

jabbany commented Jun 18, 2018

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.

@maenu
Copy link
Owner

maenu commented Jun 19, 2018

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.

@jabbany
Copy link
Contributor Author

jabbany commented Jun 19, 2018

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.

@steveoh
Copy link

steveoh commented Oct 19, 2018

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.

@quater111
Copy link

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

@jabbany
Copy link
Contributor Author

jabbany commented Apr 13, 2019

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...

@vatsala-glory
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants