130
edits
DevTools/CodingStandards: Difference between revisions
Jump to navigation
Jump to search
Added section with a list of advice for when removing eslint errors
(Added mach eslint command line, talked about .eslintignore, --no-ignore, and ESLint job on CI) |
(Added section with a list of advice for when removing eslint errors) |
||
| Line 108: | Line 108: | ||
** <code>const { foo, bar } = Cu.import("…", {});</code>, | ** <code>const { foo, bar } = Cu.import("…", {});</code>, | ||
* use Maps, Sets, WeakMaps when possible. | * use Maps, Sets, WeakMaps when possible. | ||
== Advice to patch authors == | |||
Here is list of advice for people writing new code that, hopefully, help with writing eslint-clean code: | |||
* When moving or refactoring a piece of code, consider this as an opportunity to remove all ESlint errors from this piece of code. In fact, it may even be a good opportunity to remove all ESLint errors from the entire file. | |||
* When doing ESLint-only changes, please do them in a separate patch from the actual functionality changes or bug fix. This helps make the review easier, and isolate the actual changes when looking at the source history. | |||
* When cleaning an entire file or folder from ESLint errors, do not forget to remove the corresponding entry from the <code>.eslintignore</code> file. | |||
* When writing new code, from scratch, please make it ESLint compliant from the start. This is a lot easier than having to revisit it later. | |||
* ESLint also runs on <code><script></code> tags in HTML files, so if you create new HTML test files for mochitests for example, make sure that JavaScript code in those files is free of ESLint errors. | |||
* Depending on how a dependency is loaded into a file, the symbols this dependency exports might not be considered as defined by ESLint. For instance, using <code>Cu.import("some.jsm")</code> doesn't explicitly say which symbols are now available in the scope of the file, and so using those symbols will be consider by ESLint as using undefined variables. When this happens, please avoid using the <code>/* globals ... */</code> ESLint comment (which tells it that these variables are defined). Instead, please use <code>/* import-globals-from relative/path/to/file.js */</code>. This way, you won't have a list of variables to maintain manually, the globals are going to be imported dynamically instead. | |||
* In test files (xpcshell and mochitest), all globals from the corresponding <code>head.js</code> file are imported automatically, so you don't need to define them using a <code>/* globals ... */</code> comment or a <code>/* import-globals-from head.js */</code> comment. | |||