Resolve categories inconsistencies...again

[Tlacenka]

Current behaviour

Currently, the categories become an empty array if not passed inside core config middleware. TypeScript complains about this inconsistency later on because in CoreConfig type, they are always optional.

Expected behaviour

Either the CLI should handle them as undefined and skip the section in the report instead. Or there should be two? types, one for the config provided by user and one for the refined config after middlewares.

Implementation details

Remove the default value from both middlewares (core config and only plugins).

[BioPhoton]

I would suggest going with 2 models! It was a pain from the beginning and imo the discussion on if it is a good idea to have a RC model, went no where and the problem is still here.

[hanna-skryl]

I’ve been investigating the issue with categories being optional in CoreConfig, but I couldn't find a scenario where this caused the TypeScript inconsistency mentioned. If anyone has examples of specific errors caused by this, it would really help to see them.

I’ve also looked into the idea of creating a second model to make categories required internally, but I’m unsure if this would make a difference. Since categories would just default to an empty array if missing, this seems like it wouldn’t change much from the current setup.

Any insights into the TypeScript issues or how a second model might improve things would be very helpful!

UPD: It was agreed during the discussion that the best approach would be to handle categories as undefined.