Listen360 Development Grimoire

ESlint

Our current .eslintrc.js config is as follows:

module.exports = {
  root: true,
  env: {
    node: true
  },
  extends: [
    'plugin:vue/essential',
    'plugin:prettier/recommended',
    '@vue/prettier'
  ],
  rules: {
    'no-console': process.env.NODE_ENV === 'production' ? 'error' : 'off',
    'no-debugger': process.env.NODE_ENV === 'production' ? 'error' : 'off',
    'no-unused-vars': 'off',
    'vue/component-name-in-template-casing': ['error', 'PascalCase'],
    'vue/multiline-html-element-content-newline': 'error',
    'vue/no-spaces-around-equal-signs-in-attribute': 'error',
    'vue/script-indent': [
      'error',
      2,
      {
        baseIndent: 0
      }
    ],
    'vue/no-parsing-error': 'off'
  },
  parserOptions: {
    parser: 'babel-eslint',
    sourceType: 'module',
    allowImportExportEverywhere: true
  },
  overrides: [
    {
      files: ['src/**/*', 'demo/**/*', 'tests/unit/**/*'],
      parserOptions: {
        parser: 'babel-eslint',
        sourceType: 'module'
      },
      env: {
        browser: true
      }
    },
    {
      files: ['**/*.spec.js'],
      parserOptions: {
        parser: 'babel-eslint',
        sourceType: 'module'
      },
      env: {
        jest: true
      },
      globals: {
        mount: false,
        shallowMount: false,
        createComponentMocks: false
      }
    }
  ]
}

What not to do..

  1. Never disable eslint rules unless you have very good reason to do so. All new development should abide by the chose eslint rules.
  2. Never disable eslint globally for a file.
// bad
/* eslint-disable */

// better
/* eslint-disable some-rule, some-other-rule */

// best
// nothing :)
  1. In the event you do need to disable a eslint rule, try to keep it scoped as locally as possible.
// bad
/* eslint-disable no-new */

import Foo from 'foo';

new Foo();

// better
import Foo from 'foo';

// eslint-disable-next-line no-new
new Foo();
  1. When placing eslint rule declarations, always place the on the line above the offending violation.
//bad
import Bar from './bar'
/* eslint-disable no-new */

//good
/* eslint-disable no-new */
import Bar from './bar'

Prettier

Our current .prettierrc.js is as follows:

module.exports = {
  trailingComma: 'none',
  semi: false,
  singleQuote: true,
  printWidth: 80,
  tabWidth: 2,
  useTabs: false,
  bracketSpacing: true,
  jsxBracketSameLine: false,
  arrowParens: 'avoid',
  proseWrap: 'never'
}

Modules, Imports and Exports... Oh My!

  1. Use ES module syntax to import modules
// Bad

const SomeClass = require('some_class');

// Good
import SomeClass from './some_class';

// Bad 

module.exports = SomeClass;

// Good

export default SomeClass;

Import statements should follow usual naming conventions, for example Object literals use camelCase:

export default {
  key: 'value'
}

// Bad
import ObjectLiteral from 'some_object'

// Good
import objectLiteral from 'some_object'
  1. Prefer relative paths when importing a module in the same directory, or an immediate parent directory. When importing a module which is two or more levels deep, prefer ~/.
// Bad
import Foo from '~/feature/foo';
import Bar from '~/feature/subDir/bar';
import Baz from '~/feature/subDir/lib/baz';

// Good
import Foo from '../foo';
import Bar from './bar';
import Baz from './lib/baz';

In specs:

 // Bad
 import Foo from '../../app/assets/javascripts/my-feature/foo';

 // Good
 import Foo from '~/my-feature/foo';

← Vue.js →