ESLint version

HEAD

What problem do you want to solve?

Currently, ESLint passes the raw text of a file to a processor's preprocess() method, which may include a BOM.

However, processors rarely check for the BOM before attempting to parse the text (even our own Markdown processor doesn't do the check), which can lead to hard-to-decipher parsing errors if the parser isn't handling the BOM. This seems like a serious footgun in the API that we should fix.

What do you think is the correct solution?

Instead, I think we should pass the text with the BOM removed, as it seems like that would be the most expected behavior from a processor perspective. In most cases, this will be a non-breaking change, as any processor that is checking for a BOM will still function as expected while those that do not will avoid a potential error.

The downside of this change is that processors that return a block representing the entire file in addition to subparts of the file will no longer see the BOM, which means the unicode-bom rule won't pick up a BOM in the original file when present.

If that is a concern, we can add a third parameter to preprocess() that indicates whether or not the BOM the present so processors that explicitly want to check for the BOM may do so.

(Note: Returning a block that represents the entire file is suboptimal and something we can hopefully avoid in the future with prelint plugins.)

Participation

• I am willing to submit a pull request for this change.

Additional comments

No response