@@ -11,207 +11,197 @@ See [our current .eslintrc][eslintrc] for specific rules and patterns.
...
@@ -11,207 +11,197 @@ See [our current .eslintrc][eslintrc] for specific rules and patterns.
#### ESlint
#### ESlint
-**Never** disable eslint rules unless you have a good reason. You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */` at the top, but legacy files are a special case. Any time you develop a new feature or refactor an existing one, you should abide by the eslint rules.
1.**Never** disable eslint rules unless you have a good reason. You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */` at the top, but legacy files are a special case. Any time you develop a new feature or refactor an existing one, you should abide by the eslint rules.
-**Never Ever EVER** disable eslint globally for a file
1.**Never Ever EVER** disable eslint globally for a file
```javascript
```javascript
// bad
// bad
/* eslint-disable */
/* eslint-disable */
// better
// better
/* eslint-disable some-rule, some-other-rule */
/* eslint-disable some-rule, some-other-rule */
// best
// best
// nothing :)
// nothing :)
```
```
- If you do need to disable a rule for a single violation, try to do it as locally as possible
1. If you do need to disable a rule for a single violation, try to do it as locally as possible
```javascript
```javascript
// bad
// bad
/* eslint-disable no-new */
/* eslint-disable no-new */
importFoofrom'foo';
importFoofrom'foo';
newFoo();
newFoo();
// better
// better
importFoofrom'foo';
importFoofrom'foo';
// eslint-disable-next-line no-new
// eslint-disable-next-line no-new
newFoo();
newFoo();
```
```
1. There are few rules that we need to disable due to technical debt. Which are:
1.[no-new][eslint-new]
1.[class-methods-use-this][eslint-this]
- When they are needed _always_ place ESlint directive comment blocks on the first line of a script, followed by any global declarations, then a blank newline prior to any imports or code.
1. When they are needed _always_ place ESlint directive comment blocks on the first line of a script, followed by any global declarations, then a blank newline prior to any imports or code.
```javascript
```javascript
// bad
// bad
/* global Foo */
/* global Foo */
/* eslint-disable no-new */
/* eslint-disable no-new */
importBarfrom'./bar';
importBarfrom'./bar';
// good
// good
/* eslint-disable no-new */
/* eslint-disable no-new */
/* global Foo */
/* global Foo */
importBarfrom'./bar';
importBarfrom'./bar';
```
```
-**Never** disable the `no-undef` rule. Declare globals with `/* global Foo */` instead.
1.**Never** disable the `no-undef` rule. Declare globals with `/* global Foo */` instead.
- When declaring multiple globals, always use one `/* global [name] */` line per variable.
1. When declaring multiple globals, always use one `/* global [name] */` line per variable.
```javascript
```javascript
// bad
// bad
/* globals Flash, Cookies, jQuery */
/* globals Flash, Cookies, jQuery */
// good
// good
/* global Flash */
/* global Flash */
/* global Cookies */
/* global Cookies */
/* global jQuery */
/* global jQuery */
```
```
- Use up to 3 parameters for a function or class. If you need more accept an Object instead.
1. Use up to 3 parameters for a function or class. If you need more accept an Object instead.
```javascript
```javascript
// bad
// bad
fn(p1,p2,p3,p4){}
fn(p1,p2,p3,p4){}
// good
// good
fn(options){}
fn(options){}
```
```
#### Modules, Imports, and Exports
#### Modules, Imports, and Exports
- Use ES module syntax to import modules
1. Use ES module syntax to import modules
```javascript
```javascript
// bad
// bad
require('foo');
require('foo');
// good
// good
importFoofrom'foo';
importFoofrom'foo';
// bad
// bad
module.exports=Foo;
module.exports=Foo;
// good
// good
exportdefaultFoo;
exportdefaultFoo;
```
```
- Relative paths
1. Relative paths: Unless you are writing a test, always reference other scripts using relative paths instead of `~`
* In **app/assets/javascripts**:
Unless you are writing a test, always reference other scripts using relative paths instead of `~`
```javascript
// bad
import Foo from '~/foo'
In **app/assets/javascripts**:
// good
```javascript
import Foo from '../foo';
// bad
```
importFoofrom'~/foo'
* In **spec/javascripts**:
// good
```javascript
importFoofrom'../foo';
// bad
```
import Foo from '../../app/assets/javascripts/foo'
In **spec/javascripts**:
```javascript
// bad
importFoofrom'../../app/assets/javascripts/foo'
// good
importFoofrom'~/foo';
```
- Avoid using IIFE. Although we have a lot of examples of files which wrap their contents in IIFEs (immediately-invoked function expressions), this is no longer necessary after the transition from Sprockets to webpack. Do not use them anymore and feel free to remove them when refactoring legacy code.
// good
import Foo from '~/foo';
```
- Avoid adding to the global namespace.
1. Avoid using IIFE. Although we have a lot of examples of files which wrap their contents in IIFEs (immediately-invoked function expressions), this is no longer necessary after the transition from Sprockets to webpack. Do not use them anymore and feel free to remove them when refactoring legacy code.
1. Avoid adding to the global namespace.
```javascript
```javascript
// bad
// bad
window.MyClass=class{/* ... */};
window.MyClass=class{/* ... */};
// good
// good
exportdefaultclassMyClass{/* ... */}
exportdefaultclassMyClass{/* ... */}
```
```
- Side effects are forbidden in any script which contains exports
1. Side effects are forbidden in any script which contains exports