Default Resolvers Not Resolving Relative to Given Document

Describe the bug The default resolvers don’t function as documented.

By default, http(s) and file protocols are resolved, relatively to the document Spectral lints against. [Emphasis mine]

However, when linting with a new Spectral() object, the file $refs are resolved relative to where the script runs, not the file being linted.

To Reproduce

C:/api/openapi.yaml:

openapi: 3.0.3
info:
  title: Test API
  version: 1.0.0
paths:
  /test:
    get:
      responses:
        '200':
          $ref: components.yaml#/Ok

C:/api/components.yaml:

Ok:
  description: Success

C:/dev/script.ts:

import fs from 'fs';
import YAML from 'js-yaml';
import { isOpenApiv3, Spectral } from '@stoplight/spectral';
import { DiagnosticSeverity } from '@stoplight/types';

const openApi = fs.readFileSync('C:/api/openapi.yaml', 'utf-8');

const spectral = new Spectral();
spectral.registerFormat('oas3', isOpenApiv3);
spectral.run(YAML.safeLoad(openApi) as string)
    .then(results => {
        results.filter(result => result.severity === DiagnosticSeverity.Error)
            .forEach(result => console.log(result.message))
    });

$ ts-node C:\dev\script.ts
ENOENT: no such file or directory, open 'C:\dev\components.yaml'

Expected behavior Given the OpenAPI document and script above, there should be no errors and therefore no output. Spectral’s default resolvers should be looking for C:/api/components.yaml, not C:/dev/components.yaml.

Environment:

• TypeScript: v3.9.6
• Spectral: v5.5.0
• Node: v12.15.0
• Windows: 10 Enterprise

[nulltoken]

That’s not a bad idea! Maybe between the “Linting an Object” and “Registering Formats” sections?

@dillonredding That would be great location.

Just want to clarify, by “warning”, you mean like the blockquote here (with the theme: warning comment)?

Indeed. This would bring some attention from the reader 😉

[dillonredding]

Additionally, maybe could you add a new section dedicated to linting files where those absolute/relative path concerns would absolutely shine!

That’s not a bad idea! Maybe between the “Linting an Object” and “Registering Formats” sections?

Or maybe just warnings regarding that the provided documents should be complete standalone ones (or that the resolution for relative paths would occur according to the current working directory (which location is quite unpredictable)).

Just want to clarify, by “warning”, you mean like the blockquote here (with the theme: warning comment)? I could definitely see that being helpful in “Linting a YAML String” and “Linting an Object” sections and just point to the new section.