Scan components to find asset folders to serve as static resources

[umaar]

Also:

• Updates the readme to mention the service_path
• Updates the route static tests to use tap, which has a compatible API, but provides better async support than tape
• Updates tests

---

To expand upon my change of tape to tap: tape didn't have great async support, whereas tap does. While I think there are even better test packages out there, using tap is fairly unobtrusive as it has a compatible API, and the test command doesn't even need modifying. All that changes is the require statement at the top of the file...we can do this incrementally. Tests can go from:

test('When a file that does not exist within a static route is requested', t => {
  const app = callRoutesStatic()

  request(app)
    .get('/static.txt')
    .end((err, res) => {
      t.equals(err, null, 'it should not invoke an error')
      t.equals(res.status, 404, 'it should return 404')
      t.end()
    })
})

To this:

test('When a file that does not exist within a static route is requested', async t => {
  const app = await callRoutesStatic()
  const {error, status} = await request(app).get('/static.txt')
  t.ok(error, null, 'it should invoke an error')
  t.equals(status, 404, 'it should return 404')
})

Which is better IMO.

Also converted the method signature to use objects rather than function(arg1, arg2, arg3) etc. As I think it's more readable...ideally though, if we agree, we can add such rules to a linter at some point!

[umaar]

@solidgoldpig setting this as a draft PR since this is my first. Let me know of any feedback!

/cc @asmega @theKHutDeveloper for visibility

[umaar]

Also heads up: the tests were failing for me in master and caused a bunch of confusion as a different branch (the refinement branch) had some fixes...would be good to keep master clean - having a proper PR process, where our PRs are continuously tested for linting errors, tests failures etc. and then rejected if necessary would be a good idea!

[umaar]

Code review feedback so far:

• Fix linting
• Don't use experimental Node.js features for the async stuff, but rather use Util.promisify

[umaar]

Hey @solidgoldpig thanks for looking at this! Have pulled in your changes, resolved conflicts, addressed code review feedback and now using Util.promisify instead of experimental Node.js features. If you want to have another look that'd be useful.

Also if you think it's worth doing the ava stuff in this branch, can do that, otherwise will save it for next time

[solidgoldpig]

All good.

I think leave the ava-ification for another (but soonish) time

The introduction of tap I see has now triggered a bunch of audit warnings.

Locally I ran npm audit fix and it sorted 8 out of the 9 issues, but tap's handlebars dependency (via istanbul-reports) is still complaining

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ handlebars                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.0.14 <4.1.0 || >=4.1.2                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ tap [dev]                                                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ tap > nyc > istanbul-reports > handlebars                    │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://nodesecurity.io/advisories/755                       │
└───────────────┴──────────────────────────────────────────────────────────────┘

[umaar]

For that particular remaining advisory, fortunately we are immune since the attack vector is from user supplied input. In our case, tap is only used as a dev dependency and is not exposed to the user.

Also, looking at this: handlebars-lang/handlebars.js#1495 (comment) they have fixed the issue. The version they list as fixed was the same version we had installed, I assume the NPM advisory hasn't been updated to take into account backported fixes.

I updated the package lock file anyway though

[umaar]

Update: Just to be certain, I verified 4.1.0 (which we would have installed):

• Includes the security fix
• Has been published on NPM

[solidgoldpig]

Good to go