Closed Bug 1464007 Opened 3 years ago Closed 2 years ago

Specify "html" plugin in .eslintrc.js by default for better Editor integration


(Firefox Build System :: Lint and Formatting, enhancement, P2)

3 Branch


(firefox69 fixed)

Tracking Status
firefox69 --- fixed


(Reporter: standard8, Assigned: standard8)




(1 file)

Currently, our ESLint configuration doesn't specify to use the html plugin, instead we specify the html plugin via the command line [1].

This has been because of Sublime Text's SublimeLinter / SublimeLinter-eslint configuration - it used to completely break if SublimeLinter-eslint and eslint-plugin-html were in use.

So we have the work around described above. Unfortunately this means anyone using a non-Sublime editor doesn't get to see issues in html code.

With the latest versions, we're in a slightly better position. There is now a way of configuring it so that we can get both to work together, e.g. in a configuration file add:

  "linters": {
    "eslint": {
      "selector": "source.js, text.html.basic, text.xml",

(and add "html" into the plugin options in the top-level .eslintrc.js file).

For actually doing this, I think we have only a couple of options:

1) See if we can get SublimeLinter-eslint to automatically detect html/xml files:

2) Add a `mozilla.sublime-project` file [2] to the top-level mozilla-central directory, with the appropriate configuration. Existing Sublime developers would need to move across to this project file, but newer developers could load it & get going quicker. Unfortunately Sublime doesn't have anything like VSCode's recommended options.

Note: it couldn't be just `.sublime-project` as various systems hide those files by default and Sublime's open project option doesn't show them.

Although 1) is my preferred option, I've a feeling we're going to need to go with 2). It might be better long term anyway, in case our configuration needs to change more. 

Thoughts welcome.

At the moment, 1) seems to be viable. They've already done a part refactor, and I'm trying to find out what's needed for the other one.
Sublime-Linter has given some details as to what needs to be done to provide a way in their plugin to detect eslint-plugin-html and turn off their own custom parsing:

I don't have time for that, so I'm going to look around for volunteers to do it.

In the meantime, since VS Code + Atom developers outweight Sublime ones, I'm starting to think we should potentially add the html plugin to the config by default, break Sublime, but let VS Code / Atom users be able to parse html (and also not have a different config from the command line versus the config files).
Version: Version 3 → 3 Branch

I'd love to work on this, but I havne't got time at the moment. We really could do with the SublimeLinter issue being fixed (or just ignore Sublime users).

Assignee: standard8 → nobody

Having just looked at this again, and with the prettier changes coming up, I think we should actually fix this. Last I knew there's more developers on non-sublime than there are on sublime.

If we change the default to have html enabled in the configuration rather than via the ./mach command line, then VSCode and Atom will pick up HTML ESLinting automatically. Sublime will fail to lint the html files, but it will also not show any visible errors, so it doesn't really get in the way too much.

If Sublime users want to get this working, then they can add the selector line to their user config (or help fix the issue mentioned above).

  "linters": {
    "eslint": {
      "selector": "source.js, text.html.basic, text.xml",
Assignee: nobody → standard8

This moves the html plugin enabling from the ./mach command line to the configuration, which means editors can pick this up automatically.

Pushed by
Specify the 'html' plugin in .eslintrc.js by default for better editor integration. r=mossop
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
Pushed by
Port bug 1464007 - Specify the 'html' plugin in .eslintrc.js by default for better editor integration. rs=bustage-fix DONTBUILD
You need to log in before you can comment on or make changes to this bug.