extends rulesets doesn't follow redirects

[philsturgeon]

Describe the bug

When using Unpkg (which I need to do to use my NPM-based style guide in CLI, VS Code, and Studio) I am getting Not Found if I use a version alias, possiibly because it's not following redirects.

pectral lint api/openapi.yaml --verbose
Error running Spectral!
Error #1: Could not load https://unpkg.com/@apisyouwonthate/[email protected]/dist/@stoplight/types (imported by https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js): Error fetching https://unpkg.com/@apisyouwonthate/[email protected]/dist/@stoplight/types: Not Found
          at 4/dist/
          at load                  …t/plugins/url.js:34  throw Error(`Error …
          at processTicksAndReje…  …cess/task_queues:96
          at                       …red/rollup.js:22271
          at work                  …red/rollup.js:21855  const result = awai…

This will let me set a version requirement that I am happy with, instead of having to update the patch number every time a bug fix is made.

To Reproduce

1. Make a .spectral.yaml with `extends: ["https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js"]
2. Run this CLI command 'spectral lint foo.yaml'
3. See error

Expected behavior

I would expect it to follow the redirect.

http GET https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js
HTTP/1.1 302 Found
CF-Cache-Status: MISS
CF-RAY: 746836d25edb1ead-AMS
Connection: keep-alive
Content-Type: text/plain; charset=utf-8
Date: Tue, 06 Sep 2022 15:24:54 GMT
Server: cloudflare
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
access-control-allow-origin: *
cache-control: public, s-maxage=600, max-age=60
content-encoding: gzip
fly-request-id: 01GC9PEZWAT9JTNVGQ3ACEFBMK-ams
location: /@apisyouwonthate/[email protected]/dist/ruleset.js
vary: Accept, Accept-Encoding
via: 1.1 fly.io

Found. Redirecting to /@apisyouwonthate/[email protected]/dist/ruleset.js

[P0lip]

This works somewhat as expected, although the expected behavior might be indeed not the most of folks would expect.
Basically anytime you load a ruleset over http/https, all imports you have in your ruleset must have http/https either, so they need to go through some CDN service, etc. This is in line with how ESM works in the browser.
However, we do make one exception - @stoplight/spectral-* imports can be loaded without http/https as they are treated a bit differently.

I'll have a look at it tomorrow to see if we can handle that in a better way.

[philsturgeon]

I'm not sure your reply lines up with what my understanding of the problem is. You are talking about what happens when you load the ruleset right? But we have not yet loaded the ruleset, it cannot even find the ruleset.

I am trying to load:

https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js

As you can see using the httpie example above (or use curl) that GET request is redirecting to:

https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js

Sadly Spectral isn't following that redirect.

[P0lip]

I meant the error here Error #1: Could not load https://unpkg.com/@apisyouwonthate/[email protected]/dist/@stoplight/types (imported by https://unpkg.com/@apisyouwonthate/[email protected]/dist/ruleset.js): Error fetching https://unpkg.com/@apisyouwonthate/[email protected]/dist/@stoplight/types: Not Found
or is there something else happening?

[philsturgeon]

Error being reported over here stoplightio/spectral-owasp-ruleset#14