chore: add lint step

[43081j]

Description

When doing my recent PR, I noticed a lot of small things by eye that would be caught by a linter, so here you go.

If you don't want a lint step, im happy to abandon this. Its a "while i was in there" PR.

This is Incomplete

If you want this change, you need to decide which config/guide you'd like to follow (e.g. google, airbnb).

It currently uses eslint:recommended which is very lenient. I would suggest the google config with jsdoc requirement turned off.

I do realise you use closure compiler, too, but wasn't sure if that already [tries] to pick up such issues (I haven't used CC in a while).

New Feature

• If this is a big feature with breaking changes, consider [opening an issue][issues] to discuss first. This is completely up to you, but please keep in mind that your PR might not be accepted.
• Run unit tests to ensure all existing tests are still passing
• Add new passing unit tests to cover the code introduced by your PR
• Update the readme
• Add some steps so we can test your cool new feature!
• The PR title is in the conventional commit format: e.g. feat(<area>): added new way to do this cool thing #issue-number
• Add your info to the contributors array in package.json!

Steps to Test

$ npm run lint

[frederickfogerty]

Hi there @43081j. Thank you for the PR, and thank you for picking up that we need a linter. On other projects we've used prettier, so I'd be keen to use prettier-eslint or similar here. I've added this to our backlog to fix for both this library and Drift. If this PR was updated to use prettier, that would be awesome and I'd love to merge it, but for now I'm going to reject it.

[43081j]

From what I remember, prettier-eslint is only a means of formatting your sources before they are passed through eslint, rather than a ruleset its self.

That means you'd still need a good eslint config in place to account for non-stylistic issues such as const vs let, shadowing, reassignment of a const, etc.

If you have a preference of what eslint config to use (if any, maybe just the recommended one with some extras enabled), i'd be happy to update this so it uses that and prettier-eslint.

[frederickfogerty]

Completely agree, a good ruleset is needed.

I'd like to avoid stylistic rules as much as possible and just have the non-stylistic rules turned on.

It's been a while since I've used eslint, do you have any configurations that you particularly like? It seems that eslint-config-airbnb is the most used, so if you have no preference, let's go with that.

I'll take you up on the offer to update this PR with prettier-eslint. Thanks @43081j!

[43081j]

I do like google's ruleset but combined with eslint:recommended.

We would need eslint-config-prettier to disable the stylistic rules it'll turn on, too.

I'll give it a go and see how it goes.

[43081j]

@frederickfogerty here's a first try.

it uses:

• eslint-config-google
• eslint-config-prettier (to disable stylistic rules that conflict with prettier)
• eslint:recommended (common recommended stuff)

google requires jsdoc so i changed it from error to warn and added jsdoc to the existing source.

I didn't have to add all the jsdoc but figured i may as well while im in there. if any of it sounds wrong, feel free to comment what it should be.

we didn't need prettier-eslint as we can still do npm run format just fine, and our rules don't conflict with it.

[frederickfogerty]

LGTM!