Can I control the version of spectral-rulesets used when installing spectral-cli?

[jdaly2k]

Can I can control the version of @spotlight/spectral-rules that is packaged when installing @spotlight/spectral-cli?

I use spectral-cli in a CI/CD environment that is configured to fail builds if a linter error rule is triggered. I found that the linter rules can change between installs, even when the version of spectral-cli has not changed.

From what I've observed if I install spectral-cli with NPM using:

npm i -g @stoplight/[email protected]

Then declare a ruleset that extends one of the spectral rulesets:

extends: [[spectral:asyncapi, all]]

The ruleset will be based on the latest version of spectral-rules at the time of the install:

• https://www.npmjs.com/package/@stoplight/spectral-rulesets

Is there anyway to control the ruleset version?

[philsturgeon]

There is not, but we're not about making breaking changes in rulesets unless there is a major version. For the bundled rulesets this should not be a concern.

For your own rulesets try and follow the same logic. Whoever is releasing rulesets can add new rules as warnings, and make them errors only when they're confident teams have avoided the warning. This takes a little management, but its a lot easier than adding the complexities of version management, and means new rules actually make it out into the ecosystem instead of leaving folks stuck on old versions missing most of your rules.

Or you can distribute rulesets as NPM packages and rely on the NPM version management. https://meta.stoplight.io/docs/spectral/ZG9jOjI1MTky-sharing-and-distributing-rulesets#npm

[jdaly2k]

I suspected this was the case. I'm satisfied with this answer, thanks @philsturgeon.

[P0lip]

What Phil said. For our built-in rulesets, you can also rely on NPM management and simply install @stoplight/spectral-rulesets separately and peg it to some version you're satisfied with.
Alternatively, you could just reverse the logic in your ruleset and enable rules you care about, so that new rules aren't taken into the account.

extends: [[spectral:oas, off]
rules:
  rule-a: true
  rule-b: true

To reiterate what Phil said, we aren't introducing any breaking changes to the rulesets, and if there were such we'd certainly release a new major version, thus it's generally recommended to stick with the latest version, as aside from adding rules we usually improve the existing ones.

[OllieTho]

To build off of this, I'm wanting to pin a specific version of a ruleset in spectral-rulesets (like the OAS ruleset), and I've tried using unpkg to deliver this as recommended like so:

extends:
  - https://unpkg.com/@stoplight/[email protected]/dist/oas/index.js

On the cli this gives me an error:
'@stoplight/spectral-formats' is imported as an external by @stoplight/spectral-formats?commonjs-proxy, but is already an existing non-external module id.

And in browser this fails to lint with this error:
Module "https://unpkg.com/@stoplight/[email protected]/dist/oas/index.js" that is marked with 'syntheticNamedExports: "__moduleExports"' needs an explicit export named "__moduleExports" that does not reexport an unresolved named export of the same module.

It seems that the error is arising from wanting to extend a ruleset that already exists inside the spectral package. I need a solution that is compatible with both the cli and browser versions. Any help is appreciated!