Add support for custom linting rulesets

[mheap]

This PR adds support for custom rulesets when using Insomnia and inso to lint OpenAPI specifications. This PR closes #4114, but in a completely different way to the proposal in that discussion.

This is achieved by registering a new ApiSpecRuleset type to store the ruleset (defaulting to extends: "spectral:oas" if not found to enable backwards compatibility). When in a workspace, we search for a ruleset with the same parent ID as the specification and if found, use that to configure Spectral. There is an additional Ruleset activity panel added to the Design screen to enable ruleset editing.

inso has also been updated to search for a ruleset with the same parent ID, falling back to spectral:oas.

Finally, the new ApiSpecRuleset type has been added to export and git sync

Known issues that need resolving before shipping (but I'm not sure where to start, so I'm handing it over to y'all now):

• The UI for adding a ruleset needs work. It's currently a textarea that you copy/paste in to. Editing by hand is a painful experience
• The UI for adding a ruleset does not have a sidebar (it currently just says "sidebar")
• Export did not reliably work for me. Exporting all workspaces sometimes showed the new ApiSpecRuleset entry, and sometimes it was empty

Each stage of the work required to enable this is in a single commit below. I'd recommend reviewing the whole PR as a group, then doing a deep dive on each section of functionality.

[develohpanda]

Some initial thoughts on the UI: instead of a full-page view for lint rulesets, we could put them in the WorkspaceSettingsModal alongside "Client Certificates" for example, or use a standalone modal & button for modifying lint rules. I see lint rules as being a resource for the workspace (a bit like proto files for gRPC) and don't necessarily need a full-page view. Would a modal view work for this?

[mheap]

I agree that it's not high priority enough to get a full screen on the top nav bar. Putting it under WorkspaceSettingsModal would make it too hard to find imo (I didn't even know that screen existing and had to go searching to find it just now).

Having a Customise linting rules in the dropdown could work

Edit: I should also mention that rulesets can get quite long e.g. https://github.com/Nexmo/api-specification/blob/main/.spectral.yml (and that's a short-ish customised version)

[mheap]

I'm not sure why the tests are failing. They pass fine locally:

lerna success run Ran npm script 'test' in 20 packages in 94.2s:
lerna success - insomnia-app
lerna success - insomnia-components
lerna success - insomnia-cookies
lerna success - insomnia-importers
lerna success - insomnia-inso
lerna success - insomnia-prettify
lerna success - insomnia-testing
lerna success - insomnia-url
lerna success - insomnia-xpath
lerna success - openapi-2-kong
lerna success - insomnia-plugin-base64
lerna success - insomnia-plugin-cookie-jar
lerna success - insomnia-plugin-core-themes
lerna success - insomnia-plugin-file
lerna success - insomnia-plugin-hash
lerna success - insomnia-plugin-now
lerna success - insomnia-plugin-prompt
lerna success - insomnia-plugin-request
lerna success - insomnia-plugin-response
lerna success - insomnia-plugin-uuid

[develohpanda]

Having a Customise linting rules in the dropdown could work

Sounds good. Throwing more ideas around, this could also be an opportunity to introduce plugin API so that users can configure/extend lint rules via Insomnia plugins.

[mheap]

Spectral supports extending rulesets via NPM packages (and via URL too). Let's keep the scope of this PR to what it is and we can always follow up with plugins

[ljoseph2]

@mheap is there any chance you're planning to complete this! We love the idea of this feature at our org

[mheap]

@ljoseph2 This was a proof of concept PR, which I've handed over to the Insomnia team. I believe it's planned, but no timeframe

[mheap]

Hello @Kong/team-insomnia! I spent some time rebuilding this feature on top of the latest main. There are some rough edges:

• Sidebar is empty, not sure what to put there
• The ruleset disappears on first-load rather than showing the default extends: "spectral:oas"
• I did some not so nice things to work around some assumptions that Spectral 6 makes

The feature needs more polish to be production-ready, but this is enough for us to demo as needed

[jackkav]

Closing in favour of implicit .spectral.yaml file detection approach in #5488 inso cli approach complete. UI approach TBD