Integrate prettier

[char0n]

https://github.com/prettier/prettier

[char0n]

@Undistraction wrote:

@char0n WIth prettier you have to just accept that there are very few config options. That is actually the best thing about it, but if you are used to finessing how you like things to look it will be a hard at first. I honestly think it is the single biggest time-saver you can use in writing JS. So much less distraction from silly little decisions about formatting. It's very fast too.

[char0n]

@Undistraction what is the workflow ? Do I understand correctly that you don't need linting if you use it ? I've also seen using eslint + prettier working together in some projects.

[Undistraction]

It's not a linter, it's a code formatter. It works by turning the code into an AST, then rendering it. This means its really consistent - it isn't trying to change elements of the code, but always runs a full transform on everything. ESlint is actually both a linter and a formatter (if you use its autofix). So you want to use Prettier for formatting and ESlint for linting. You can do this just by disabling the autofixing for Eslint.

I use VSCode and have it setup to run prettier every time I save a file.

My prettierrc:

{
  "printWidth": 80,
  "tabWidth": 2,
  "semi": false,
  "singleQuote": true,
  "trailingComma": "es5",
  "overrides": [
    {
      "files": ".prettierrc",
      "options": { "parser": "json" }
    },
    {
      "files": ".babelrc",
      "options": { "parser": "json" }
    }
  ]
}

You might need to tweak a few eslint rules to get them to play nicely (So prettier isn't doing things that eslint doesn't like. Here is my .eslint.js. Note that it extends the prettier config and uses the prettier plugin.

module.exports = {
  extends: [
    'eslint-config-airbnb-base',
    'prettier',
    'plugin:ramda/recommended',
  ],
  plugins: ['prettier', 'eslint-plugin-ramda'],
  env: {
    browser: true,
    jest: true,
  },
  parserOptions: {
    sourceType: 'module',
    ecmaFeatures: {
      jsx: true,
    },
  },
  globals: {
    l: true,
  },
  rules: {
    'func-names': ['error', 'never'],
    'no-param-reassign': 'off',
    'import/no-extraneous-dependencies': 'off',
    'no-confusing-arrow': 'off',
    quotes: [
      'error',
      'backtick',
      { avoidEscape: true, allowTemplateLiterals: true },
    ],
    'jsx-quotes': ['error', 'prefer-double'],
    'comma-dangle': ['error', 'always-multiline'],
    'valid-jsdoc': ['error'],
    'no-restricted-syntax': ['error', 'LabeledStatement', 'WithStatement'],
    'import/extensions': ['off', 'never'],
    'no-unused-vars': [
      'error',
      {
        argsIgnorePattern: '^_$',
      },
    ],
    'ramda/always-simplification': ['error'],
    'ramda/compose-simplification': ['error'],
    'ramda/eq-by-simplification': ['error'],
    'ramda/prefer-complement': ['error'],
  },
};

They are rock solid and work great together.

You can confidently drop semi-colons with prettier and it will add them in only when needed. I have also found switching to using backticks for all strings is a huge timesaver so I don't need to change the delimiter if I need to insert a value or use single quotes.

I'd be happy to get this setup, but it's probably worth you having a run at it yourself just to get your head round it.

[char0n]

Feel free to issue a PR and I'll play with it in the PR. I am planning to give it a go on Oracle project I'm currently working on to bring consistency into codebase.

Regarding using template literals all the time, I had a debate on it with some guys in the past, I still prefer to visually distinguish between strings and dynamic template literals but I guess that only matter of subjective taste.

[Undistraction]

I think it's just one of those things that feels wrong until you do it and after a day you don't give it another thought. For me the time saving alone is a big win. It really adds up.

[char0n]

Very nice job! Added 2 codeclime issues as exceptions.