Improvement proposal: support of SlimerJS

[Laurent Jouanneau]

Hello,


I'm developping a new scriptable browser, SlimerJS, similar to PhantomJS, but based on Gecko, the rendering engine of Firefox. It will allow to do tests on your website with Gecko/Firefox, like you do with PhantomJS. And with CasperJS of course :)

http://slimerjs.org

The PhantomJS API is not fully implemented yet into SlimerJS, but we can do many things right now. We can do simple tests with CasperJS for example :-)

To launch CasperJS with SlimerJS, some changes have been needed (I opened an issue https://github.com/n1k0/casperjs/issues/482)

We could use PHANTOMJS_EXECUTABLE to indicate the Slimerjs binary, but IMHO, it is not really easy to switch quickly between phantomjs and slimerjs.
So I propose the support of a --slimerjs flag on the command line to indicate to use Slimerjs, with the support of a SLIMERJS_EXECUTABLE environment variable.

https://github.com/laurentj/casperjs/commit/2194875d94de8b22390b43c6089a803f12a8af6d

SlimerJS provides an API to indicate different paths where to load modules, for the require() function, and since SlimerJS has a different module loader than PhantomJS (it load modules in their own sandbox for example), it's a difficult to redefine the require() function like CasperJS does with patchRequire(). So I propose also a patch for the support of patchRequire(): https://github.com/laurentj/casperjs/commit/084980431d35787e9667e46939aa7809e8df207d

If you are ok with this patches, I'll do a pull request of my branch https://github.com/laurentj/casperjs/commits/slimerjs


Laurent

[Nicolas Perriault]

On Thu, May 16, 2013 at 12:22 PM, Laurent Jouanneau
<ljoua...@gmail.com> wrote:

> http://slimerjs.org

> with CasperJS of course :)

This is GREAT news, thanks for your work

> I propose the support of a --slimerjs flag on the command line to
> indicate to use Slimerjs, with the support of a SLIMERJS_EXECUTABLE
> environment variable.

What do you think of a --engine option instead? so we could either
pass --engine=phantomjs (the default) or --engine=slimerjs and it
would be a bit more easy to add more engines in the future (hey, let
me dream)

> SlimerJS provides an API to indicate different paths where to load modules,
> for the require() function, and since SlimerJS has a different module loader
> than PhantomJS (it load modules in their own sandbox for example), it's a
> difficult to redefine the require() function like CasperJS does with
> patchRequire(). So I propose also a patch for the support of patchRequire():
> https://github.com/laurentj/casperjs/commit/084980431d35787e9667e46939aa7809e8df207d

That require.paths is interesting, I think we should ask for it to be
supported in PhantomJS don't you think?

> If you are ok with this patches, I'll do a pull request of my branch
> https://github.com/laurentj/casperjs/commits/slimerjs

Let me review this this week-end. Thanks for all the work.

Cheers,

--
Nicolas Perriault
https://nicolas.perriault.net/
Phone: +33 (0) 660 92 08 67

[Laurent Jouanneau]

Hi,

Le jeudi 16 mai 2013 20:54:21 UTC+2, Nicolas Perriault a écrit :

On Thu, May 16, 2013 at 12:22 PM, Laurent Jouanneau
<ljoua...@gmail.com> wrote:

> http://slimerjs.org
> with CasperJS of course :)

This is GREAT news, thanks for your work

> I propose the support of a --slimerjs flag on the command line to
> indicate to use Slimerjs, with the support of a SLIMERJS_EXECUTABLE
> environment variable.

What do you think of a --engine option instead? so we could either
pass --engine=phantomjs (the default) or --engine=slimerjs and it
would be a bit more easy to add more engines in the future (hey, let
me dream)

Yes, that's a good idea. What about the environment variable ? do we try to retrieve <given_engine_name_in_uppercase>_EXECUTABLE?

 

> SlimerJS provides an API to indicate different paths where to load modules,
> for the require() function, and since SlimerJS has a different module loader
> than PhantomJS (it load modules in their own sandbox for example), it's a
> difficult to redefine the require() function like CasperJS does with
> patchRequire(). So I propose also a patch for the support of patchRequire():
> https://github.com/laurentj/casperjs/commit/084980431d35787e9667e46939aa7809e8df207d

That require.paths is interesting, I think we should ask for it to be
supported in PhantomJS don't you think?

Yes, I did: https://github.com/ariya/phantomjs/issues/11339
 

[Nicolas Perriault]

On Mon, May 20, 2013 at 11:44 PM, Laurent Jouanneau
<ljoua...@gmail.com> wrote:

> Yes, that's a good idea. What about the environment variable ? do we try to
> retrieve <given_engine_name_in_uppercase>_EXECUTABLE?

Sounds like a good option. so we could have a SUPPORTED_ENGINES dict like:

SUPPORTED_ENGINES = {
'phantomjs': 'PHANTOMJS_EXECUTABLE',
'slimerjs': 'SLIMERJS_EXECUTABLE'
}

Keys being the option name, throwing an error if the one the user
passes is not supported.

> Yes, I did: https://github.com/ariya/phantomjs/issues/11339

I've just +1 this one, let's cross fingers

++

[Laurent Jouanneau]

Ok
We have to deal with specific options too... I see how to do.

Laurent