New: Access to options in processors

[Conduitry]

Summary

This would add the ability to send options to processors, via a new processorOptions object in the .eslintrc configuration.

Related Issues

https://gitter.im/eslint/eslint?at=5d0e804ad4535e477a829360

Rendered RFC

Here

WIP Implementation

Here

[jsf-clabot]

All committers have signed the CLA.

[platinumazure]

I like this proposal and have no objections at this point. (Leaving as a comment to reduce chance of accidental early merge, but I'll come back and approve later.)

I think it makes sense to pass just the settings, but it might be best to wrap them in an object in case we want to add even more logic to processors in the future- better to have one options object which includes options.settings (and whatever else in future) rather than continuing to add to number of positional arguments. Just my two cents.

Thanks for putting this together!

[Conduitry]

I like the idea of an options object containing just { settings } for now. I'm not sure what the process is here. Is this the sort of thing I would edit into my PR now, or should we wait for more people to weigh in?

[platinumazure]

Is this the sort of thing I would edit into my PR now, or should we wait for more people to weigh in?

I would say it's your call. Feel free to edit it in if you think it's likely nobody will push back or come up with something better. 😄

The RFC should definitely evolve in response to feedback over time. This is a process that will take at least a few weeks, so we greatly appreciate your patience!

[mysticatea]

Thank you for your contribution.

The options for processors sounds good to me.

I have some suggestions:

• I think that adding processorOptions property is more proper than reusing settings property. Because we have processor property since ESLint 6.0.0, it will be similar to the pair of parser and parserOptions. Symmetry gives us good predictability.
• Would you add an example in the Detailed Design section? It would help to understand this proposal.
• For the Documentation section, I think that we need two updates for both plugin authors and users.

[Conduitry]

Oh, I like processorOptions. That seems tidier, and it makes sense not to cram these in with the other settings.

[ilyavolodin]

I think it's fine to just provide the whole config object to both pre- and postprocessors. They work as a pair and shouldn't require any isolation.

[ilyavolodin]

That should be the only place. Processors are pretty isolated from the rest of the code, as they have been a late addition.

[ilyavolodin]

It looks like this RFC has been open for over 21 days required for Initial Commenting stage, and there doesn't seem to be disagreements on the content of the RFC, so I'm going to move it into Final Commenting stage.

[platinumazure]

I like the idea of having a processorOptions object rather than sending the whole config. It is consistent with parserOptions and gives plugin authors the opportunity to design a clean interface. Also, I can't see any strong need for processors to access the rest of configuration (though I would love to see a counterexample).

[kaicataldo]

I think it makes sense to start by limiting processors access to just processorOptions to begin with, with the understanding that we can add more in without it being a breaking change. That would be more consistent with parserOptions (where we do add pass in a few more configuration keys, including ecmaFeatures, ecmaVersion, and enabled envs).

[Conduitry]

Anything else needed before this is merged?

As mentioned in the OP, I do have an implementation of this in a fork that seems to be working. I plan on submitting a PR for this. Is there any avenue in particular that I should be asking for help with stuff like writing tests for this?

[platinumazure]

@Conduitry

Anything else needed before this is merged?

Probably not, but I'm not sure. This has been in the final commenting period for 7 days and I haven't seen any explicit objections in that time.

In particular, we don't need to have an implementation PR up before we merge this.

@ilyavolodin Do you have any concerns with creating a processorOptions configuration key, rather than sending in the whole config?

Is there any avenue in particular that I should be asking for help with stuff like writing tests for this?

I don't think there's anything special here. You could reach out on our Gitter chat or ask questions in the implementation PR itself, depending on how far we are in implementation. Hope this helps!

[ilyavolodin]

@ilyavolodin Do you have any concerns with creating a processorOptions configuration key, rather than sending in the whole config?

No I think that's fine. My comment was about sending the same information to pre/post processors, not specifically about the whole config.

[platinumazure]

My comment was about sending the same information to pre/post processors, not specifically about the whole config.

Sorry for misunderstanding. I agree we should send the same information to both preprocessors and postprocessors.

Anything else we need before merging this?

[mysticatea]

I think that this RFC is good to finish. Thank you very much, @Conduitry !