Differentially treat specific blocks (use new processor API)

[brettz9]

Description

#123 ties into this (and perhaps could be considered with this), though that issue is focused on inline event handler blocks, and this issue is more for the blocks that are already discovered by eslint-plugin-html (though supporting their differential treatment).

If supporting the new ESLint processor API, (as eslint-plugin-markdown is now doing in their v2.0.0), this should I think allow eslint-plugin-html to support the following:

1. Applying specific overrides config (rules, etc.) for specific script tags
2. type="module" on the script tags could be used to determine whether the blocks are modules or not (rather than project parserOptions.sourceType config) they should be weaved together for purposes of undefined/unused variables (since files can have a mix of type or no type).

(Of course, one would only wish to do this if the current beneficial ability to treat the blocks as tied together for purposes of undefined/used variables could be continued when non-module scripts were in use. If necessary, perhaps the non-modules could be strung together even if it means they could not have separate config, while allowing the modules to be treated as the separate entities they are.)

Alternatives

One can use external files and lint those by file name.

Additional context

See:

• https://eslint.org/docs/developer-guide/working-with-plugins#processors-in-plugins
• https://eslint.org/docs/user-guide/configuring/plugins#specifying-processor

I'll admit this is not a burning need I have, but I figured it might be worth a look given ESLint's support for the approach, and that the Markdown plugin is now doing so.

Thanks for the great plug-in!

[BenoitZugmeyer]

This is a very good suggestion and I would be in favor of exploiting those new APIs and remove a bit of dirty monkey patching from my plugin 😃 But as you noted, the biggest challenge is to mark variables as defined and used accross script tags (for non-module scripts). The processor API also lacks the ability to access the configuration settings part, which is used when parsing to know if it is XML or HTML, or which type= arguments should be considered as JS scripts, among other things.

I will keep this in mind and may find a way to use the new APIs while keeping a bit of monkeypatching for the blocking points.

[JounQin]

@BenoitZugmeyer

Are you working on this? It should not be difficult based on my experience by fixing eslint-plugin-markdown's issues and developing eslint-plugin-mdx, and fixing other tools' issues due to processor API.

If you haven't started, I can help to start the job when I'm free.

[Airkro]

I create https://github.com/nice-move/eslint-plugin-html to do this, not been published yet.

I'm a rookie at making Eslint plugins, please send me feedback and code reviews.

[brettz9]

@Airkro : Ni hao and congratulations on getting a plugin working! It's great to see some movement on this, and it look like you took a sound approach.

However, besides benefiting the other users of this plugin, a PR might ensure that all of the logic with markVariableAsUsed is not lost. That code is needed because the scripts in HTML are not completely independent of each other, and one doesn't want the no-unused-vars rule reporting a variable used in a later block which was defined in an earlier one.

[Airkro]

@brettz9

I want to send a PR to https://github.com/BenoitZugmeyer/eslint-plugin-html, but it's difficult for me. let's see if anyone can help?

I try to read the code of eslint-plugin-html, it's really complex, I didn't understand every part yet. And I think htmlparser2 APIs are not friendly enough.

But I will try to solute the no-unused-vars problem someday.

[Standard8]

@Airkro I think you'd need to fork this repository, then copy your changes across from your repo into the fork on a new branch. You could then push your changes to your fork and request a PR from there.

[Standard8]

The processor API also lacks the ability to access the configuration settings part, which is used when parsing to know if it is XML or HTML,

One option here would be to provide to different processors in the plugin - one for xml and one for html. The configuration can then specify which processor to use for which file extension.

or which type= arguments should be considered as JS scripts, among other things.

I think it might be reasonable to ask core ESLint for an extension of the API to allow specifying the module/script type in the return options of preprocess.