Error with extending ruleset from an NPM package

[exoszajzbuk]

The following error occurs when defining.spectral.js in a project repo which would extend a ruleset from a private NPM package (in this case @team-supercharge/oasg/ruleset)

import oasgRuleset from '@team-supercharge/oasg/ruleset';

export default {
  extends: oasgRuleset,
}

The extension seems to be trying to load the dependency from a CDN, previous versions (using Spectral 5) used to correctly trying to load the @team-supercharge/oasg/ruleset locally from the node_modules directory.

[Error - 09:43:31] An error occurred while validating document /Users/bali/Devel/project/api/spec.openapi.yaml: Unable to read ruleset at /Users/bali/Devel/project/.spectral.js. Error: Could not load https://cdn.skypack.dev/-/@team-supercharge/oasg@v10.0.2-2VJzdTnx52EvLlWlHHZk/dist=es2019,mode=raw/ruleset (imported by https://cdn.skypack.dev/@team-supercharge/oasg/ruleset): Error fetching https://cdn.skypack.dev/-/@team-supercharge/oasg@v10.0.2-2VJzdTnx52EvLlWlHHZk/dist=es2019,mode=raw/ruleset: Not Found

When using a YAML ruleset .spectral.yaml the following error occurs:

extends: '@team-supercharge/oasg/ruleset'

[Error - 09:59:44] An error occurred while validating document /Users/bali/Devel/project/api/spec.openapi.yaml: Unable to read ruleset at /Users/bali/Devel/project/.spectral.yaml. Error: Could not load /Users/bali/Devel/project/@team-supercharge/oasg/ruleset (imported by .spectral.js): ENOENT: no such file or directory, open '/Users/bali/Devel/project/@team-supercharge/oasg/ruleset'

In this case the extension tries to load the ruleset from the project folder, instead of from inside node_modules.

In both cases running Spectral from the CLI works totally fine.

Environment:

• Extension version: 1.1.2
• VS Code version: 1.78.2
• Operating System: macOS Ventura

[exoszajzbuk]

any updates on this?

[sduc]

I'm seeing the same issue. It seems like it is not looking into the node_modules folder but only at the root of the workspace. The cli work perfectly fine but not the vscode extension.

[sduc]

There is a hack to make it work @exoszajzbuk you can just point the the path to your dep. for example we have a @bastion-technologies/spectral-ruleset npm package and we can just add

extends:
    - "node_modules/@bastion-technologies/spectral-ruleset/dist/ruleset.js"

in the .spectral.yml file in the repo.
Not idea but works until the extension supports npm packages rulesets.

Note that it also works with the cli in case you also use it in your CIs for example.

[Gouveia15]

Hello everyone, just opened a pull request that can fix this problem, #218 .
Waiting for some feedback, thanks!

[afmhenry]

I have a similar issue, but when applying non-ruleset node packages in my custom scripts.

FetchError: Could not load

Is there any workaround for that?

[kennethaasan]

I have the same issue. Does #218 fix this?

[exoszajzbuk]

Can #218 be merged to fix this issue?

[frankkilcommins]

Hi folks,

Although #218 was closed, the latest spectral packages have been included in v1.1.4 of the extension (which now also supports linting of AsyncAPI v3 and Arazzo v1).

In my quick test for this issue, the following base configuration works as I can get feedback on OWASP rules via the extension:

extends: [spectral:oas, "@stoplight/spectral-owasp-ruleset"]

[erwinkramer]

@frankkilcommins it still only works for me if i change your sample to:

extends: [spectral:oas, "node_modules/@stoplight/spectral-owasp-ruleset/dist/ruleset.mjs"] 

But that also required me to install it manually: npm install @stoplight/spectral-owasp-ruleset

If i just try your sample as-is, the Spectral output shows:

Error: Could not load c:/myvscodeproject/@stoplight/spectral-owasp-ruleset (imported by .spectral.js): ENOENT: no such file or directory, open 'c:\myvscodeproject\@stoplight\spectral-owasp-ruleset'

Some more tests:

These works:

https://unpkg.com/@stoplight/spectral-owasp-ruleset@2.0.1/dist/ruleset.js
https://unpkg.com/@backmarket-api/rulesets

This doesn't:

https://unpkg.com/@stoplight/spectral-owasp-ruleset

So it also seems to depend per package implementation.