Skip to content
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

Fix: Validate options after applying defaults, not before #165

Open
JoshuaKGoldberg opened this issue Jun 10, 2024 · 2 comments · May be fixed by #166
Open

Fix: Validate options after applying defaults, not before #165

JoshuaKGoldberg opened this issue Jun 10, 2024 · 2 comments · May be fixed by #166
Labels

Comments

@JoshuaKGoldberg
Copy link

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.

@mdjermanovic
Copy link
Member

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.

@JoshuaKGoldberg
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Implementing
Development

Successfully merging a pull request may close this issue.

3 participants