The plan is to make sure contrib modules use ESLint and fix all errors they have. We want all Drupal JS to be as clean as possible. For that we need to make sure the big modules are using it and fix their JS, the smaller modules should follow afterwards.
- Find a contrib module with a lot of users and check it for any eslint errors
- Check if a 8.0.x version is in development
- Search the queue for "ESLint errors"
- If there is nothing, create a new issue with the template below
- (bonus) Make a patch!
Remember, we're not here to judge the JS of the module, we're here to make sure it's following standards. That's it. Be nice!
Then create a new issue following this template, replace
<project> with the name of the contrib module you're working on:
|Version||Any 8.x dev version|
|Parent issue||2490140 Very important, otherwise we can't track things properly|
|Files||The output of eslint in a
Obtained by running (from the Drupal root or with Drupal
Seefor an example.
Sometimes some rules needs to be changed for specific modules (if they use a third party library and they need to use a new global variable), in that case the module can create it's own
.eslintrc turning some rules on or off and adding global variables they require. When ESLint runs, all the configuration files present in the directory tree are merged together: see Configuration Cascading and Hierarchy for more details.
Following modules are already linted and do not need to be checked:
- Display Suite