v0.8.6 fails to show proper error on invalid schema

[dlouzan]

Detailed description

The latest 0.8.6 version fails to print proper advice on invalid specs:

> speccy lint swagger.json

./node_modules/speccy/lint.js:83
        const { context, lintResults } = _options;
                ^

TypeError: Cannot destructure property `context` of 'undefined' or 'null'.
    at validator.validate (./node_modules/speccy/lint.js:83:42)
    at ./node_modules/call-me-maybe/index.js:13:28
    at process._tickCallback (internal/process/next_tick.js:61:11)

whereas version 0.8.5 properly hints at the underlying issue:

> speccy lint swagger.json

Specification schema is invalid.

#/paths/~1api<hidden>/post/parameters/0
path parameters must appear in the path

Context

I'm working on linting both v2 (using swagger2openapi) and v3 files from an older project. Some of the existing v2 files had not been linted before, and seems they are not even spec compliant.

The nodejs exception does not help finding out where the error actually lies, it looks to a user as if speccy is having an issue, instead of parsing an invalid spec.

Your environment

• Node Version: Both latest v8 & v10 via nvm
• Operating system and version: Debian 9.6

[dlouzan]

Actually, when comparing the output of this to the older swagger-tools validate, it seems to stop at the first error, whereas swagger-tools shows all errors in a single pass. Is it possible to obtain something like that? I think it's much nicer for the user:

API Errors:

  #/paths/~1api<hidden>/post/parameters/0/<hidden>: API path parameter could not be resolved: <hidden>
  #/paths/~1api<hidden>/post/parameters/1/<hidden>: API path parameter could not be resolved: <hidden>
  #/paths/~1api<hidden>/get: API requires path parameter but it is not defined: <hidden>
  #/paths/~1api<hidden>/get: API requires path parameter but it is not defined: <hidden>

4 errors and 0 warnings

Thanks for the awesome work!

[pderaaij]

This will be fixed when version 2.0.1 of oas-validator is released and updated in speccy.

[MikeRalphson]

v2.0.1 of oas-validator has just been published.

[philsturgeon]

Fixed in master, will be included in next release.

[chris-branch]

This still seems to be broken in the master branch. I see that oas-validator was updated to 2.0.1 in #246

And I see a second PR that was closed because oas-validator 2.0.1 was supposedly going to fix this, but it's still throwing the same exception as documented above even with oas-validator 2.0.1

Also, the fix shown in the PR that was closed (#238) does seem to resolve the problem