chore(lint): turn on more jsdoc lint rules

[cjquines]

follow-up #558

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 2ef1042:

Sandbox	Source
remeda-example-vanilla	Configuration

[codecov]

Codecov Report

Attention: Patch coverage is 92.53731% with 5 lines in your changes are missing coverage. Please review.

Project coverage is 98.51%. Comparing base (96a4e82) to head (2ef1042).
Report is 64 commits behind head on master.

Files	Patch %	Lines
src/compact.ts	0.00%	1 Missing and 1 partial ⚠️
src/noop.ts	0.00%	1 Missing and 1 partial ⚠️
src/countBy.ts	0.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #580      +/-   ##
==========================================
+ Coverage   98.41%   98.51%   +0.09%     
==========================================
  Files         127      152      +25     
  Lines        7954    10486    +2532     
  Branches      724      875     +151     
==========================================
+ Hits         7828    10330    +2502     
- Misses        123      153      +30     
  Partials        3        3              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[eranhirsch]

Let's wait with this PR for after the v2 release. We haven't decided yet if we are adding dataLast impls to guards, and if not it might mean we need to relax the rule to allow some functions not to be tagged with dataFirst and dataLast.

[cjquines]

are the non-datafirst and non-datalast rules fine?

i do think require-jsdoc and require-throws are useful to have on (they caught that the groupBy jsdoc was misplaced, for example) and that having signature be required is also useful (it caught times not having a signature, which causes it not to appear in the docs i think?)

[eranhirsch]

are the non-datafirst and non-datalast rules fine?

We'll have to circle back on this once v2 is out so we can see what the state of the library is. I tend to say I prefer them, but I've also noticed that we could simply drop the tags and the duplication of the docblocks and have one documentation block for both... It's a pain to update docs right now as it's just copy-pasting between the 2 versions to fix the example and signature slightly. It was useful when purrying was done manually, but those exceptions are so rare (I think only zipWith) that we're better off just having less optimal docs for that one case.

[cjquines]

yeah, i've been thinking about this too... it's kind of a pain having the docs duplicated. i think tsserver will show the docs for the first overload if the other overloads don't have docs anyway, so it's probably fine, but it would be a change... hm...

[cjquines]

bringing back the discussion of having two docs, one advantage is that tsserver can serve different docs for each one, so we can get the descriptions for each parameter while we're typing it. but i can only get this to work in vscode:

in neovim with tsserver it's a bit different, though maybe it's with how i configured it:

with only one jsdoc, we don't get the full documentation for the other overloads while we're typing, though we do get it on mouseover

i could do a more careful write-up if we want to investigate this further?

[eranhirsch]

Those are good points to keep the duplication, at least for now. We can consider writing a "linting" script that would check that the dataFirst and dataLast description have the same content and fail the build if they don't, but it also makes sense in some cases to have 2 different descriptions. e.g. we can remove the "pipable" tag (that should be renamed to "lazy" in v2) from the dataFirst impls.