Fix args regression: readme --shallow --format (Invalid second argument)

[hugojosefson]

There was a regression regarding arguments, introduced in [email protected] (227db1c) when the yargs dependency was upgraded in package.json from ^6.0.1 to ^9.0.1.

yargs@7 is more strict on correctness of how it's used, which is what caused the error YError: Invalid second argument. Expected object but received string.

This PR fixes that, and updates yarn.lock based on package.json because that hadn't been done in a while.

Now documentation readme --shallow --format=.... works again.

---

Fixes #959.
Similar to PR #953.

[coveralls]

Coverage remained the same at 86.098% when pulling d84d835 on hugojosefson:fix-args-regression into 1d6fe80 on documentationjs:master.

[coveralls]

Coverage remained the same at 86.098% when pulling 1048bdf on hugojosefson:fix-args-regression into 1d6fe80 on documentationjs:master.

[coveralls]

Coverage remained the same at 86.098% when pulling a5f0b05 on hugojosefson:fix-args-regression into 1d6fe80 on documentationjs:master.

[mmoss]

Fingers crossed this get traction soon! 😁

[anthony-redFox]

Why lodash and not Object.assign?

[hugojosefson]

To be consistent with how sharedOptions were applied in serve.js.

Thanks for pointing it out!

I checked http://node.green/#ES2015-built-in-extensions-Object-static-methods-Object-assign and can see that it is indeed supported since node@4 (which this project already requires), so I added a commit now to replace all _.assign() with Object.assign().

[anthony-redFox]

It is doesn't work for me. I agree that --verbose option is deprecated but in version 6.

[hugojosefson]

Yes, and to me it seems to possibly have happened even earlier :) Good thing you updated the dependency now! I'll leave your change to the precommit run-script.

[coveralls]

Coverage remained the same at 86.098% when pulling 1d33435 on hugojosefson:fix-args-regression into b6e7e7d on documentationjs:master.

[hugojosefson]

@anthony-redFox I get this flow error now in src/infer/params.js:

Error: src/infer/params.js:200
                  v-------------
200:       return Object.assign(
201:         paramToDoc(
202:           param.value,
...:
208:       );
           ^ property `name` of object literal. Property not found in
             v----------
201:         paramToDoc(
202:           param.value,
203:           prefix + '.' + param.key.name || param.key.value
204:         ),
             ^ Array

It seems it's because flow can't be sure paramToDoc() doesn't return an Array, because its signature says it might:

documentation/src/infer/params.js

Line 104 in 37d188a

): CommentTag | Array<CommentTag> {

I'm hesitant to override the error message, because I don't know enough about the program to understand if it's a genuine possible bug. Do you know if it could ever return an Array in that case? Should I simply cast like this?

    case 'ObjectProperty': {
      return Object.assign(
        ((paramToDoc(
          param.value,
          prefix + '.' + param.key.name || param.key.value
        ): any): CommentTag),
        {
          name: prefix + '.' + param.key.name || param.key.value
        }
      );
    }

[hugojosefson]

Added the flow override for the time being. Merge only if you agree.

(It doesn't change how the code works. Only keeps hiding it like lodash used to do.)

[coveralls]

Coverage remained the same at 86.098% when pulling 5e7365a on hugojosefson:fix-args-regression into b6e7e7d on documentationjs:master.

[tmcw]

I'm fine with the Flow override in this case. Really wish I hadn't allowed some of these methods to return such different values, makes working with Flow lamer. Something to fix up in the future.

[hugojosefson]

Thanks, @tmcw

[anthony-redFox]

@hugojosefson Thanks.