Bryan Mishkin

@nzakas okay, given your preference, I'm fine with keeping the current behavior of throwing an exception for null/undefined. The benefit of this choice is that we maintain only a single...

@mdjermanovic I agree with your thoughts (throw on everything except an object). However, I am still a bit perplexed by the concern around disallowing arrays/functions. In general, I believe: 1....

> ...why are we cutting off at testing for arrays and functions? Why not maps and sets? This is a good point. I think the reasoning comes from how one...

Just trying to make sure I understand this proposal. I'm assuming the current proposal is: * Shareable configs can set `'some-cool-rule': 'default'` * End-users can set `defaultSeverity: 'error'` / `defaultSeverity:...

The severity override alternative I was describing would look like this (@LukeSamkharadze originally suggested it in a comment above): Turn warnings off: ```js { severity: { warn: 'off' } }...

Sorry for the delay. Should be ready if still interested.

This could be solved with an optional `minimumLength` option on the [eslint-comments/require-description](https://mysticatea.github.io/eslint-plugin-eslint-comments/rules/require-description.html) rule.

This is out of the rule's control. ESLint rules aren't aware of whether the user enables them with `warn` or `error` severity. And the autofixer can be used anytime the...

As a counterpoint to changing the default, if you want to disable a rule for an entire file, it's actually better practice to use this comment style instead: ``` /*...

The commit `refactor: remove other unused code` doesn't look right, I think that code is still used.