chore: use standard

[bnb]

Switches to using Standard rather than lintit, after noticing that the code style was relatively... different than most modern JavaScript I've seen.

Switching to Standard did require several bits of refactoring outside of the normal standard --fix to make the CLI compliant, including moving to new URL() rather than url.parse(), shifting around some inline functions, and tweaking a few of the RegEx (did my best to validate that they would still do what they should with external tooling in addition to running npm run test).

cc @codebytere

[codecov]

Codecov Report

Merging #84 into master will decrease coverage by 0.44%.
The diff coverage is 45.23%.

@@            Coverage Diff             @@
##           master      #84      +/-   ##
==========================================
- Coverage   60.93%   60.49%   -0.45%     
==========================================
  Files          18       18              
  Lines         448      443       -5     
==========================================
- Hits          273      268       -5     
  Misses        175      175              

Impacted Files	Coverage Δ
lib/rule.js	100.00% <ø> (ø)
lib/rules/line-after-title.js	100.00% <ø> (ø)
lib/rules/metadata-end.js	100.00% <ø> (ø)
lib/rules/pr-url.js	100.00% <ø> (ø)
lib/rules/reviewers.js	100.00% <ø> (ø)
lib/rules/subsystem.js	100.00% <ø> (ø)
lib/rules/title-length.js	100.00% <ø> (ø)
lib/tap.js	5.26% <ø> (ø)
bin/cmd.js	29.88% <12.00%> (-1.58%)	⬇️
lib/format-tap.js	4.76% <50.00%> (ø)
... and 6 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2ddbb6d...ad3eafd. Read the comment docs.

[Trott]

I know it's more work for you as the contributor, but I'd prefer that the refactors go in their own commits, or even their own PRs. I'm talking about the url.parse()/new URL() changes in one commit (or one PR), and the regular expression changes in another commit (or PR), and so on, then all the purely aesthetic changes that can be done with --fix in their own commit/PR.

[bnb]

@Trott if you'd like, I can do that.

The challenge there is that I had to incrementally run standard --fix since the main CLI file (and I believe one other file, though that one was just a tiny change so I didn't focus on it too much) is actually so far out of what's expected/acceptable by standard that it messes up the parsing to the point it fails. I had to incrementally apply changes and then fix several times.

If you do want me to do that, are you okay with each step in that process being an incremental commit (including multiple fix commits)?

[Trott]

The challenge there is that I had to incrementally run standard --fix since the main CLI file (and I believe one other file, though that one was just a tiny change so I didn't focus on it too much) is actually so far out of what's expected/acceptable by standard that it messes up the parsing to the point it fails. I had to incrementally apply changes and then fix several times.

Does running standard --fix and doing nothing else result in a file that no longer parses? Or am I misunderstanding?

[Trott]

Oh, I see. Parsing errors because it doesn't permit return to exit the CLI script and things like that. In ESLint, you can configure it to permit that. standard/standard#167

[Trott]

I'm fine with whatever. I'm just less likely to invest the time to review if I can't easily skip over everything that standard auto-fixes and focus on the other things. But that's just me!

[bnb]

Oh, I see. Parsing errors because it doesn't permit return to exit the CLI script and things like that. In ESLint, you can configure it to permit that. standard/standard#167

There were a couple things like that, but instead of changing standard I approached it by exiting the process (which is actually what @feross suggested as a workaround in that issue). Can discuss that when I refactor, though. Will take a stab at this tomorrow 👍

[bnb]

reset to the commit before the initial commit I PR'ed and force pushed the changes 👍

[Trott]

We're either going to want to squash everything into one commit when landing, or else split this into two commits: One commit at the start to remove lintit and one commit at the end to add standard.

[Trott]

reset to the commit before the initial commit I PR'ed and force pushed the changes 👍

Thanks for doing all that. It made reviewing it a lot easier (for me, at least).

[codebytere]

looks good to me, but in agreement with @Trott we should probably split the lintit removal into a discrete commit

[feross]

@bnb If you need to silence certain warnings temporarily for this PR, you can add this to the top of a file:

/* eslint-disable no-use-before-define */

More info: https://standardjs.com/#how-do-i-hide-a-certain-warning

[bnb]

@Trott / @codebytere is this something I should do or is it something you'd do when merging?

[codebytere]

On second thought i'm fine just squashing everything into a single commit!