Revert type changes from #1088

[jnoordsij]

This reverts commit 9545160.

Summary

In #1088 a generic key, any combination was added to BaseValidation. This allows one to use arbitrary possibly incorrect accessing of properties on v$ (say v$.somethingThatDoesNotExist) without TypeScript errors, given that TypeScript infers any and basically stops checking. Therefore I think the introduced change degrades the quality of the types in this package.

The issue as presented in #1088 seems to be caused not by an incorrect typing in the type declarations, but rather by a missing generic argument, as seems to be implied by the listed Validation<ValidationArgs<unknown>, unknown> type description. If one ensures that in the scope of e.g. useVuelidate the generic T for the state argument is properly detected, actual values should be properly accessible on the resulting object.

Metadata

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes (theoretically for people relying on the new broken behavior; limited to TypeScript failure as there are no runtime changes)
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• I have read the Contribution Guides
• It's submitted to the next branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuelidate/vuelidate/blob/master/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

[jnoordsij]

@tomosterlund I'm wondering if the alternative solution for your previous issue (i.e. #1088) as I've tried to describe above will solve it without needing your change, with the additional benefit of actually having proper types on the accessed properties. Would be great to have your input on this!

[tomosterlund]

@jnoordsij I'm no longer developing any app with Vuelidate, so I won't have the use case to try it out. But if the same problem can be solved by generics and without losing type safety, it sounds like the right choice!

My PR from 2022 has to be seen in the light of being created by a TS-noob who at that point didn't know generics :) Thanks for including me your considerations though.

[jnoordsij]

@jnoordsij I'm no longer developing any app with Vuelidate, so I won't have the use case to try it out. But if the same problem can be solved by generics and without losing type safety, it sounds like the right choice!

My PR from 2022 has to be seen in the light of being created by a TS-noob who at that point didn't know generics :) Thanks for including me your considerations though.

Thanks for writing back, I think reverting this should be the way forward then!

@dobromir-hristov given my encountered issue and the reaction above, do you think it's possible to move forward with this?