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

Repo: Rule [options] parameter should be non-nullable if defaultOptions exists #5439

Open
JoshuaKGoldberg opened this issue Aug 7, 2022 · 2 comments
Labels
accepting prs Go ahead, send a pull request that resolves this issue blocked by another PR PRs which are ready to go but waiting on another PR repo maintenance things to do with maintenance of the repo, and not with code/docs
Milestone

Comments

@JoshuaKGoldberg
Copy link
Member

JoshuaKGoldberg commented Aug 7, 2022

Suggestion

Right now, if a rule is created through util.createRule with defaultOptions, the create function's second parameter is an array whose first element is still Options | undefined. That means folks have to !. For example, in #5327:

create(context, [_options]) {
const options = _options!;

Unless I've grossly misinterpreted the rule options, those ! should be unnecessary, right?

Edit: here's a TypeScript playground with an isolated repro.

@JoshuaKGoldberg JoshuaKGoldberg added triage Waiting for maintainers to take a look repo maintenance things to do with maintenance of the repo, and not with code/docs labels Aug 7, 2022
@bradzacher bradzacher added accepting prs Go ahead, send a pull request that resolves this issue and removed triage Waiting for maintainers to take a look labels Aug 13, 2022
@JoshuaKGoldberg JoshuaKGoldberg added this to the 8.0.0 milestone Feb 3, 2024
@JoshuaKGoldberg
Copy link
Member Author

We've deleted lines-around-comment in the v8 branch. A new still-in-the-repo example is consistent-type-imports:

defaultOptions: [
{
prefer: 'type-imports',
disallowTypeAnnotations: true,
fixStyle: 'separate-type-imports',
},
],
create(context, [option]) {
const prefer = option.prefer ?? 'type-imports';

@JoshuaKGoldberg
Copy link
Member Author

#9025 touches a lot of the same interfaces, so marking as blocked on that one till it's merged.

@JoshuaKGoldberg JoshuaKGoldberg added the blocked by another PR PRs which are ready to go but waiting on another PR label Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting prs Go ahead, send a pull request that resolves this issue blocked by another PR PRs which are ready to go but waiting on another PR repo maintenance things to do with maintenance of the repo, and not with code/docs
Projects
None yet
Development

No branches or pull requests

2 participants