You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coming over from eslint/eslint#17656 (comment): right now, eslintrc validates options and then validates defaults. Copying the example from @mdjermanovic's comment, if this is a rule:
{meta: {defaultOptions: [{foo: 42}],schema: [{type: "object",maxProperties: 2// allows one or two in addition to "foo"?}]},create(){return{};}}
...then the configuration ["error", { bar: 6, baz: 7 }] is still considered valid.
This is different from the new ESLint flat config format.
Technically this proposed stricter behavior could be considered a breaking change and out of scope given this package's feature freeze. However, I'd propose we consider it a bugfix, as IMO the invalid options should not have been allowed to begin with.
Filing a tracking issue for my reference. I plan on sending a PR for this soon, unless directed otherwise.
The text was updated successfully, but these errors were encountered:
Technically this proposed stricter behavior could be considered a breaking change
Can you clarify this? meta.defaultOptions is a new feature, so I believe there is no previous behavior compared to which this would be a breaking change.
Can you clarify this? meta.defaultOptions is a new feature, so I believe there is no previous behavior compared to which this would be a breaking change.
Oh, I was thinking if a rule happened to already have meta.defaultOptions defined by coincidence. But you're right that this shouldn't affect any properly written existing rules.
Coming over from eslint/eslint#17656 (comment): right now, eslintrc validates options and then validates defaults. Copying the example from @mdjermanovic's comment, if this is a rule:
...then the configuration
["error", { bar: 6, baz: 7 }]
is still considered valid.This is different from the new ESLint flat config format.
Technically this proposed stricter behavior could be considered a breaking change and out of scope given this package's feature freeze. However, I'd propose we consider it a bugfix, as IMO the invalid options should not have been allowed to begin with.
Filing a tracking issue for my reference. I plan on sending a PR for this soon, unless directed otherwise.
The text was updated successfully, but these errors were encountered: