feat: Prelint plugins

[nzakas]

Summary

This RFC introduces the concept of a "prelint", which is like a rule but it runs before any linting happens, allowing plugins to modify the behavior of subsequent linting runs.

This requires #99 to function and was split off from that RFC.

Related Issues

https://github.com/eslint/rfcs/pull/99 https://github.com/eslint/eslint/issues/14745

[ljharb]

Does this include a way for a rule to declare a dependency on a prelint, and implicitly "add" it to the prelint list if not already present?

[nzakas]

@ljharb no. Rules cannot force users to add other rules, prelints, or configurations. At least to start, rules should specify what they’re expecting in their docs. Plug-ins can, of course, publish configs that contain appropriate “known good” settings.

[ljharb]

Gotcha - that's fine, it just means this doesn't solve the use case of allowing rules to execute a "before" step.

[nzakas]

@ljharb is there a specific use case you have in mind?

[ljharb]

Yes, I want eslint-plugin-import's rules to be able to indicate that they need an "initialization" step, to cache the module graph, and for eslint to automatically queue up the Promise ordering as appropriate, and to skip the initialization step when no active rules require it.

[nzakas]

Ah okay, thanks for the explanation. I'll need to think about that use case a bit more, but I don't think it fits within this RFC.

[nzakas]

@JamesHenry this RFC might be of interest to you, as well.

[JamesHenry]

Thanks @nzakas I can comment on the big 3 projects I work on:

Based on my understanding, I think it would just give an alternative to the use of processors for angular-eslint - I don't think it has any major advantages of the current implementation (but also no major disadvantages)

For typescript-eslint and Nx, I don't think this would change much, I think for those two we would need something much more like what @ljharb is describing

[nzakas]

@JamesHenry thanks for the feedback. Indeed, I'm viewing this as a more flexible replacement for processors rather than something radically different. The primary different is that it would allow us to lint both the original file and all of the virtual files, whereas processors only allow linting of virtual files.

[nzakas]

Updated to simplify the creation of fragments out of a file. You no longer need to manually manipulate the text before passing it back to ESLint. Let me know what you think.

@eslint/eslint-tsc still waiting for the first round of feedback on this.

[brettz9]

Hi,

Just wanted to confirm--would this support multiple levels of nesting with languages?

My use case would be for @example tags containing JavaScript to lint within a JSDoc block "language" (so that the blocks could have their own AST which rules could target), within the main JavaScript file.

So after parsing the main JavaScript AST, we'd want to find the /** */ blocks and parse their contents as our own JSDoc AST, and then when finding @example within the latter, parse its inner contents again as JavaScript AST.

[nzakas]

Yes, based on your config it could go multiple levels deep. So if you have a Markdown file that has a JavaScript block, that would get pulled out, and then any prelints configured for JavaScript files would run. So, if the JavaScript block contained a block of GraphQL, a prelint could pull that out as separate from the Markdown and JavaScript that it was embedded within.