[FEAT] Allow fetching reporters directly from module resolver

[andypalmer]

This PR allows jshint to find reporters via the module resolver, as well as falling back to the existing search relative to the current path.

If the package.json has a main clause that points to the reporter (see e.g. https://github.com/riverglide/jshint-junit-reporter.git ), then the reporter can be specified as just the module name (e.g. jshint --reporter @riverglide/jshint-junit-reporter vs jshint --reporter node_modules/@riverglide/jshint-junit-reporter/reporter.js)

[coveralls]

Coverage remained the same at 100.0% when pulling 0e6acdd on andypalmer:master into b23f046 on jshint:master.

[jugglinmike]

Thanks for the patch! This is a nice improvement. The directory structure within node_modules is not guaranteed, so folks generally shouldn't be relying on any particular path. JSHint's current behavior therefore encourages a bad practice (for non-local reporters, anyway). From that perspective, the approach you've enabled here doesn't just make their code more readable: it makes it more stable.

Would you mind adding a test for this?

[andypalmer]

The test would also be more a test of nodes require.resolve functionality, but given that the driver for the patch was my move to Yarn's PnP resolution that might still reveal some surprises.

It would require adding an external dependency to the project. I'd feel a lot more comfortable about doing that if there was an external reporter under the jshint organisation so that we don't have a potential test failure outside of our control. (This could also provide the exemplar of how to write an external reporter, including the package.json and reporter tests independent of jshint)

It'd probably be better for the dependency to come via the npm registry than directly via github. My suggestion would be @jshint/example-reporter.

Does that all sound reasonable?

[jugglinmike]

It does sound reasonable, but we may be able to avoid the indirection of another npm module. npm supports modules installed by file path; we may be able to use that to keep the new test's dependencies in the tree. That's kind of uncommon use for the functionality we're discussing here, but the goal is just to demonstrate propery integration with npm, and I think that'd do.

It looks like this behavior relies on npm link under the hood, so we'd have to shell out to npm before running the test.

What do you think?

(By the way, you'll be glad to know that the project already includes an example reporter for demonstration purposes.)