Allow an `/* eslint */` alternative to apply until overridden by another such directive (or if disabled)

Hi,

I sometimes have need for a rule to have different configuration within a single file. The inline /* eslint */ directive is close to what I want as it allows defining a rule inline, but doesn’t seem to allow changing within a file.

I do not wish to use /* eslint-disable */ directives as I want the rule to apply at different points, just with different options.

For example, in one file, I want to add:

  /* eslint 'jsdoc/require-jsdoc':
    ['error', {contexts: ['Property']}] */

…preceding an object whose properties I want to be forced to have a jsdoc description.

But I don’t want properties everywhere in the document to be forced to have jsdoc blocks as this would be very cumbersome for our project, yet it appears to be the case when I use the directive as above.

I see that adding a subsequent /* eslint */ directive will override the previous one, but the overriding directive will then apply (retroactively) to the whole file and not only to the content following it.

I’d therefore like to have a directive which can add or change a rule and later change the options for that rule (and ideally also be able to revert to the default, especially since some rules configuration can be very verbose).

Note that I do not wish to entirely disable the rule, so having, for example, an overrides specific to this file and then using disable/enable directives does not suffice for my use case.

(Also, if I can ask, as I assume it has been considered, why single-line comments are not supported, e.g., // eslint-disable doesn’t work though /* eslint-disable */ does?)

Update: Note that the proposed directive would need to be disabled when running no-inline-config.

[mysticatea]

In common, rules use information from the whole code in order to report errors, therefore I think that context.getOptions(loc) will introduce huge complexity to the ecosystem. I can’t think it’s good.

Instead, maybe, linter can make multiple instances of a rule for each option if option’s changes existed in the code, then ignore errors outside of valid ranges. In that case, I think that the ecosystem doesn’t need to fix their rules except for the rules that use global state.

[mdjermanovic]

This makes sense, but it looks like a serious breaking change for rules (core rules and plugins).

In order to support this, context.options should be removed from the API and replaced with something like context.getOptions(loc) where loc is the location that would be reported.