Allow custom parser as parameter about protractor-flake

[NickTomlin]

Yep! This is definitely on the roadmap but I'd love a PR on this if you have time!

I was thinking about the ability to pass in a filename and have that be required by protractor flake. It would just have to return an array of files to retest.

[phgnx]

Sorry for the delay, I've been quite busy.

Would you prefer :

• Add an option which will give the path to be required assuming the parser value is set to "custom" into the index
• Update the getParser function to try to require the name (which might actually be a path so maybe a bit confusing) if !all[name]
• A mix of both, based on a second optional parameter supported by the getParser method and returning the require if the first one is set to custom ?

Maybe there is a better way to do it.

For the testing part :

• Unit : this one for me would be a bit complex to be test, I can create a custom parser but since the parser used will be fully custom it will be more about "How to create my custom parser" documentation
• IT : No difficulties here, I can just spawn the command and test different use cases (Valid/Invalid custom parser), on my side I'll probably wrote them in typescript with an interface/implementation for transpilation checks

I can do the PR but I need to clarify those points before :)

[NickTomlin]

Sorry for the late reply!

This is an interesting question, let's think about a few options for calling it

# an additional option
protractor-flake --require-parser /path/to/parser.js

# make parser "smart"
protractor-flake --parser/path/to/parser.js

# add an option to require a file
protractor-flake --require /path/to/parser.js --parser 'name-of-custom-parser'

My initial reaction is that it would be worth it to try something fancy like protractor-flake --parser/path/to/parser.js.

We could take a few approaches:

1. Require that parsers include the full extension .js/.ts/.es6 and assume that any parser name that ends with a . should be required
2. Require that users specify an absolute path and look for / or \
3. Attempt to require a parser at the path if one doesn't exist for that name (seems sort of flakey)

As for testing, i'd just create a custom parser fixture and pass that to whatever test you use. That way there's no way to do anything weird with files, it would just be required from the test. We could even use a tmp directory if we wanted to be sure there wasn't anything project specific that was interfering with this.

Let me know what you think!

[NickTomlin]

Support for custom parsers was released in 2.2.0 9791183