Configure ESLint to require JSDoc @params etc

[colinrotherham]

This PR follows up #2913 (optional JSDoc) by making @param tags mandatory for methods that use JSDoc

It also configures ESLint excluded files correctly using excludedFiles

Which continues work we started for v4.4.0:

• Enable ESLint JSDoc checks #2913
• Various JSDoc + type checking fixes (for v4.4.0 only) #2997

To assist with code reviews I've split these changes into:

1. Ensure JSDoc blocks are complete #3102
2. Configure ESLint to require JSDoc @params etc #3103
3. Various JSDoc + type checking fixes #2987
4. Enable type declaration guards #3123
5. Add (optional) type declaration checks in app, src #3104

Resolves #2513

[romaricpascal]

Makes all sense to me 🙌🏻 but I'm quite partial to the JSDoc work already. Might be worth getting a quick check with the team before we enforce adding JSDoc 😄

[romaricpascal]

Looks like the 'warn' value snuck back in or maybe you yere you looking to enable require-param-type instead, as that's what we need for typing?

[colinrotherham]

@romaricpascal Oh I probably misunderstood, it's been moved from .eslintrc.js to src/.eslintrc.js

As in, JSDoc params (and descriptions) are only needed for our user-facing source code for documentation

Think we should have it optional everywhere?

Thanks

[colinrotherham]

I've gone ahead and removed the warnings for @param + descriptions

It's something we can monitor during code reviews. Don't want to hassle ongoing spikes with linting issues

(Also set enableFixer: false so ESLint --fix won't keep adding placeholder @param either)

[domoscargin]

Given that the code already meets these settings, I think it makes sense to formalise the jsdoc requirements.

[colinrotherham]

Given that the code already meets these settings, I think it makes sense to formalise the jsdoc requirements.

Thanks @domoscargin 👍

@romaricpascal I know you were keen on adding warnings when we've missed type declarations (plus stricter checks for missing @param + descriptions) but only if the team agrees that's what we want

(Need to weigh up the benefits of valid types for publishing versus quick spikes where things change quickly)

So I'll go ahead and merge this one as-is and we can tighten further if wanted in future