chore: update typescript to v5 and synchronise predefined rulesets through strict typing

[tatomyr]

What/Why/How?

When adding rules, we have to export them from index files, add into our predefined rulesets, and list in the config validation file (redocly-yaml.ts). Currently they are not completely in sync with each other. Introducing strict typing helps to fix the discrepancies.

However, TS v4 works inconsistently, so I updated it to v5. This caused update/installation of several other packages (including Jest and ESLint).

Note

Most of the updated test files are merely a clean-up after upgrading to Jest v29. Exceptions are: load.test.ts, config-resolvers.test.ts.snap and this snapshot.

Nothing should change for users.

Open questions:

• Should the previously omitted rules use severity 'off' or 'error' in the all ruleset? -> 'error'
• Are we going to create a separate async2 section in our rulesets like we have for exclusive OAS2/3 rules? (See here). cc @lornajane

Reference

Testing

Screenshots (optional)

Check yourself

• Code is linted
• Tested with redoc/reference-docs/workflows (internal)
• All new/updated code is covered with tests

Security

• Security impact of change has been considered
• Code follows company security practices and guidelines

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6114bd9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

Command	Mean [s]	Min [s]	Max [s]	Relative
redocly lint packages/core/src/benchmark/benches/rebilly.yaml	1.299 ± 0.028	1.257	1.337	1.01 ± 0.04
redocly-next lint packages/core/src/benchmark/benches/rebilly.yaml	1.292 ± 0.037	1.242	1.367	1.00

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	75.94%	4022/5296
🟡	Branches	65.78%	2138/3250
🟡	Functions	68.06%	652/958
🟡	Lines	76.13%	3770/4952

Test suite run success

640 tests passing in 93 suites.

Report generated by 🧪jest coverage report action from 6114bd9

[lornajane]

I think the async2 rules (and in future async3) should have the same sections as the oas2/3 ones do, does that answer the question?

Also I have a question about where you removed all the off rules. Does this make them show up as unused as a warning in the command output? The Async2 linting without any parameters produces more output than I expected and I have been meaning to look if that's because I haven't configured all the other rules to be off.

[tatomyr]

I think the async2 rules (and in future async3) should have the same sections as the oas2/3 ones do

Ok, I'll add channels-kebab-case and no-channel-trailing-slash to the rulesets. Which severity should it be for minimal/recommended?

The Async2 linting without any parameters produces more output than I expected

@lornajane this is partially related to my question :) I believe it's because the rules section in the rulesets implies that the linter runs ALL of them for any API docs type (OAS2/3 and Async2). If we want to show only appropriate ones, we have to reconsider the rules to only contain a really COMMON subset of rules, and move all that don't match into separate sections.

[lornajane]

I think only spec (error) and operation-operationId (warn) rules make sense for the recommended ruleset for AsyncAPI, the others are rather a matter of taste (and the way AsyncAPI does tags is quite weird so probably those rules need some attention anyway). We may adjust this over time as we learn how people use the rules in their own projects.

[roman-sainchuk]

LGTM 👍

[IgorKarpiuk]

👍