fix(ruleset-migrator): url loaded rulesets fail to resolve npm installed rulesets

[jquick-axway]

Checklist

• Tests added / updated
• Docs added / updated

Does this PR introduce a breaking change?

• Yes
• No

Summary:
A remotely loaded ruleset will fail to load if it extends an npm/yarn installed ruleset such as:

• "@stoplight/spectral-owasp-ruleset"
• "spectral-aws-apigateway-ruleset"

This is NOT an issue if the remote ruleset extends core rulesets "spectral:oas" and "spectral:asyncapi" because of the check here.

Cause:
In the resolveModule() method, the path.isURL(ctx.filepath) check will return true for a remote ruleset and not bother to check if the module/identifier is an npm installed module via the requireResolve() method. This causes the npm installed module to wrongly resolve to a relative URL path and 404.

Notes:
The isPackageImport() method will wrongly return true if my remote ruleset extends another ruleset in the same remote path. So, I'm testing the identifier if it is in fact installed via requireResolve().

We also can't assume all module names will be prefixed @, because it would fail to find spectral-aws-apigateway-ruleset.

Steps to reproduce:

1. NPM install the owasp ruleset.
   npm install --save -D @stoplight/spectral-owasp-ruleset
2. Lint with a remote ruleset file that extends that npm installed owasp ruleset.
   spectral lint -r https://raw.githubusercontent.com/jquick-axway/spectral-test-rulesets/main/api-linting/owasp.yaml https://raw.githubusercontent.com/jquick-axway/spectral-test-rulesets/main/api-linting/tests/openapi-v3.json
3. The following error gets outputted. Note that the @stoplight/spectral-owasp-ruleset is resolving to a URL instead of the npm locally installed module.
   Could not load https://raw.githubusercontent.com/jquick-axway/spectral-test-rulesets/main/api-linting/@stoplight/spectral-owasp-ruleset (imported by https://raw.githubusercontent.com/jquick-axway/spectral-test-rulesets/main/api-linting/.spectral.js): Error fetching https://raw.githubusercontent.com/jquick-axway/spectral-test-rulesets/main/api-linting/@stoplight/spectral-owasp-ruleset: Not Found

[P0lip]

In the resolveModule() method, the path.isURL(ctx.filepath) check will return true for a remote ruleset and not bother to check if the module/identifier is an npm installed module via the requireResolve() method.

In general, that behavior is expected. If you serve a ruleset over http/https, it is now expected the ruleset won't have any local dependency. Some usages like imports in custom functions may still accept that, but in the longer term one will need to follow ES modules.
This is to ensure such a ruleset can be loaded in a browser environment without any issues.
You can change the extends in your rulesets to use Skypack or unpkg.com

[jquick-axway]

Yes, I can change the "extends" to a URL of the owasp/aws ruleset.
(Although my goal is to let people upload a ruleset as-is.)

But I see this as a module resolution issue. Spectral changing something like...
@stoplight/spectral-owasp-ruleset
...to...
<MyRulesetBaseUrl>/@stoplight/spectral-owasp-ruleset
...isn't going to work unless you duplicate that ruleset on the server "without" the yaml file extension. And like you said, the remote custom JS functions support importing what's locally npm intsalled (which is a behavior I'm also depending on).

[mnaumanali94]

Closing as expected.