environment variable

feat: Do spectral validation calls

Apifant

Allows switching between different rulesets, might be useful later on.

Currently supported values: v5,v10

…n-for-spectral-rules

Snyk has created this PR to upgrade react-redux from 7.2.8 to 7.2.9.

See this package in npm:
https://www.npmjs.com/package/react-redux

See this project in Snyk:
https://app.snyk.io/org/huk-coburg/project/6781dd8e-dbe8-4e84-86b5-f2f4515c956a?utm_source=github&utm_medium=referral&page=upgrade-pr

…63d5639f754488

[Snyk] Upgrade react-redux from 7.2.8 to 7.2.9

…al-rules

First draft: Dropdown for spectral rules

Snyk has created this PR to upgrade swagger-client from 3.19.2 to 3.19.3.

See this package in npm:
https://www.npmjs.com/package/swagger-client

See this project in Snyk:
https://app.snyk.io/org/huk-coburg/project/6781dd8e-dbe8-4e84-86b5-f2f4515c956a?utm_source=github&utm_medium=referral&page=upgrade-pr

Backport of changes introduced in #6. Not entirely sure what happens
here, this seems to be a timing issue.

Not giving an explicit `source` to the messages means they go into the
same pool as the default messages, this also means that they fall into
the same cleanup logic. The `newSpecErrBatch` function seems to mess with
that cleanup (our spectral messages clean up the "regular messages") and
the UI tries to render messages that no longer exist, crashing in the
process.

the `newThrownErrBatch` function doesn't seem to have these issues but
it requires a debounce for some reason or it won't render anything.

…fined

fix(spectral): Fix validation crashing the UI

We might have in-flight validation attempts
that need to be cancelled when a new one is about to be issued
or we risk getting the same issue displayed multiple times
if the timing is exactly right/wrong and both complete after all `arg.errActions.clear` have run.

To work around this we use an AbortController, fetch has built-in support for that.
Sadly the easy solution of globally creating a controller and then simply sending an abort()
on every run of validateSpec will immediately cancel the new fetch that is supposed to happen.

To work around this a new AbortController is constructed on every run of validateSpec and stored in the controller variable.
The controller variable is null at start and will be set back to null after every fetch() call.
If it isn't null when validateSpec is called then this must mean that a request is currently going on and that can be cancelled.
Overriding the controller afterwards with a new AbortController will avoid the signal also cancelling the new fetch() call

Co-authored-by: Erlwein, Björn <[email protected]>

…4525545682bac0

[Snyk] Upgrade swagger-client from 3.19.2 to 3.19.3