-
Notifications
You must be signed in to change notification settings - Fork 919
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: config validation #2408
Comments
|
yes, its same package as eslint is currently using https://github.com/eslint/eslint/blob/75fea9bcdd3dde5a07e0089d9011a4df518cdbe3/package.json#L51 |
i updated proposal a little, to make it more clear |
json schema, based on SchemaStore/schemastore#1443 |
I believe this done because the PR was merged |
sadly no, this describes 2 part of config validation, and only first part has been implemented "Rules validation" is not yet implemented |
Ah, thanks! Was wondering for a moment... |
Context
While working on #2398 I noticed that we are not validating if config provided has correct structure at all, in this pr i added basic validation for resolved configuration as doing unsafe type casting is really bad idea
Proposed implementation in not ideal, and requires more refining.
Proposal
Create new package responsible for validation of configuration and rules
@commitlint/config-validator
and use ajv to validate configurations loaded by@commitlint/load
and@commitlint/resolve-extends
Validation should be done in 2 steps: config and rules
Config validation #2412
this should be first step of validation of config structure and type check properties, but it should not validate structure of specific rules as by default we should accept any configuration that matches
Rules validation
after resolving and merging all extended configs we should proceed to validate
options
for rules:this is going to require change in structure of rule definition, we should add support for object and deprecate raw functions
in case if we don't have schema for rule, we should skip validation of
options
Rule as object
schema property is optional, but recommended,
options
against itoptions
as any/unknownRule as function - backward compatibility
It should be threated as there is no schema provided and we should accept any
options
Why we should change default structure of rules
with moving away of simple function structure it gives us possibility:
ability to expose json-schema for IDE to provide syntax autocompletionthis is my general idea for this, its not written in best way, but I'd like to hear your opinion on this
The text was updated successfully, but these errors were encountered: