-
-
Notifications
You must be signed in to change notification settings - Fork 12
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
Change Request: Make enforcement of schema optional #67
Comments
Is there a reason something like this won't work? const acceptEverything = new Proxy({}, {
get() {
return {
merge: 'replace',
validate() { },
}
},
});
const configArray = new ConfigArray(configs, {
basePath,
schema: acceptEverything,
}) |
Is there a reason why something like that can not be given through a shorthand? :) const configArray = new ConfigArray(configs, {
basePath,
noSchemaEnforcement: true,
}) The intent from both the perspective of I would opt for the |
Yes, because this is not an intended use of the utility. The whole point of this package is to enforce a schema, so it doesn't make sense to add an option telling it not to. It doesn't make sense to provide a shorthand for something that is an exception case, especially when there is a user-land solution. |
@nzakas Could we maybe get an official published Eslint Flat Config schema then? So that one can use the correct schema? |
Which packages would you like to change?
@eslint/compat
@eslint/config-array
@eslint/migrate-config
@eslint/object-schema
What problem do you want to solve?
One challenge when making use of
@eslint/config-array
to consume ESLint Flat Configs from a third party module is that the ESLint Flat Config schema is not published: eslint/eslint#18619 (comment)This makes
@eslint/config-array
throw due to unexpected properties in the config objects.To avoid this I opted for making a mostly non-enforcing minimal schema in eslint/config-inspector#69:
What do you think is the correct solution?
Instead of trying to mimic a non-published schema I would like to accept all schemas in a case like eslint/config-inspector#69
Pretty much a:
As the current
flatConfigNoopSchema
will fail if the actual ESLint Flat Config schema is extended with an additional top level key.Participation
Additional comments
As mentioned in eslint/eslint#18619 (comment), an alternative in this specific case is for sure to publish the ESLint Flat Config schema so that the
@eslint/config-inspector
can consume it, but since eg.@eslint/config-inspector
is only interested in thefiles
andignores
it does not need to validate the config schemas and could in theory at its core be made to support more types of config arrays than ESLint Flat Config.And the fact that the ESLint Flat Config schema is not published is indicative that there are cases where the config schema will not be published but consumption by a third party through
@eslint/config-inspector
is still desired.Another alternative that was considered was to consume the ESLint
FlatConfigArray
instead, but that would expose too much of the ESLint internals and be inflexible for ESLint: eslint/eslint#18619 (comment)The text was updated successfully, but these errors were encountered: