I still hold my dissent. Think about function calls:

parseCode(code,{failfast:true});

We can refactor that intoparseCode({ code, failfast: true }), but do we want to?

Differentiating between a primary option and a secondary option highlights the former's importance. The primary option isn't just any option: it determines the entire behavior of the rule. Having"consistent-generic-constructors": ["error", "type-annotation"] is synonymous to"parameter-properties": ["error", "always"]—if we change the primary option, the rule's reports will be completely inverted. This should not happen with secondary options, whichrefine the existing reports (e.g. check more positions, or ignore some cases).

Rules that have a primary option are, really, two rules smashed together, with a string option to toggle between two modes. For example, we can imagine splittingconsistent-generic-constructors intoprefer-constructor-type-arguments andno-constructor-type-arguments, with completely opposite reports. The only reason we are not doing that is because this is against ESLint's API design norms of "don't have opposing rules".