feat(config): add extraRoutes to scully.config

[aaronfrost]

With the additional of extraRoutes to the scully.config, users can now provide additional routes
that they want Scully to discover. These routes can plug into the router plugins as well, and can
produce multitudes of browsable routes each.

I need this feature to integrate with our first big enterprise client.

In your scully config, you can now provide an extraRoutes that looks like an Angular route (meaning it contains parameters). These can be routes that exist in AngularJS, or in React, or in whatever Framework's router. What's really important is that this unlocks our ability to support Angular Hybrid scenarios where some routes are controlled by Angular and others controlled by AngularJS. The Guessjs parser will find the Angular routes. But won't find the AngularJS routes. This extraRoutes field allows me a place to specify all of the AngularJS routes I would like Scully to render as well.

exports.config = {
    ...
    extraRoutes: [
        "/donuts",
        "/donuts/:donutId"
    ]
}

The example would now have a route with a parameter in it. I could then configure a routerPlugin to fetch those donut id. I would do that the same as if I was doing it for an Angular route.

exports.config = {
    ...
    routes: {
        "/donuts/:donutId": {
            type: "myCustomDonutIdPlugin"
        }
    },
    extraRoutes: [
        "/donuts",
        "/donuts/:donutId"
    ]
}

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/scullyio/scully/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[aaronfrost]

instead of simply allowing people to provide a string[] as the type of config.extraRotues, we could allow the type of extra routes to be (string | string[] | Promise | Promise<string[]>)[], which we could just flatten it all and then turn them all into promises, and run a Promises.all([flattenedAndPromisifiedExtraRoutes]) and then return them.

That is likely the most extensible and support the most amount of people. But... for now, I support this list of strings gets us quite a ways.

[SanderElias]

I would prefer to have the promise<string[]>, as that is indeed the most extensible.
For now, I can live with this. I probably need to do a bit of redesign anyway, so we can start generating "pages" before we are done collecting all routes anyway.

[SanderElias]

LGTM

[SanderElias]

I would prefer to have the promise<string[]>, as that is indeed the most extensible.
For now, I can live with this. I probably need to do a bit of redesign anyway, so we can start generating "pages" before we are done collecting all routes anyway.

[aaronfrost]

@SanderElias please read this now. I changed it to allow you to pass a hodge-podge array of string and promises, and it will take care of resolving everything, removing empty values, and flattening nested arrays of unhandled routes.

[ '/user/:id', Promise<string>, Promise<string[]>, undefined]

gets turned into

['/user/:id', '/foo/:id', '/bar/:id', '/baz/:id']

[SanderElias]

awsome, that is even more as I would have wanted ;)