eslint-config-charlike

Code style: Charlike. Self preferences on top of Standard Style v9 release. They may or may not be included in next releases.

Table of Contents

• Notes
  • Changes
  • Adds
  • Badge
• Install
• Usage
• Related
• Contributing
• Building docs
• Running tests
• Author
• License

(TOC generated by verb using markdown-toc)

Notes

This config extends standard v9 javascript style and just add few more rules to it, which leads to more readable code. Most of the rules here, are already suggested in the Standard repo, but they are just proposals, so they may or may not be included in the v9 or v10 version of the Standard. I just want one very stable place with all needed things included. Don't want separate CLI too, since we have ESLint CLI which works great.

Status: Locked

• Does not accepts changes - everyone can sit on top of it, like this sits on top of Standard
• Meant to be used as config, won't include CLI - probably, not make much sense
• This isn't a CLI tool - we have ESLint CLI already

Changes

Most noticeable change is that we

• Disallow computed property spacing, this foo[ 'bar' ] is just too ugly - computed-property-spacing
  • Standard allows both styles, through the eslint-plugin-standard option called either

Adds

In addition we have few more rules

• Maximum line length should always be strictly 80, we ignore comments - max-len
• Maximum params to be 3, hence more leads to very big and complex code/functions - max-params
  • If that's your case, you are encouraged to split your code more
• Always use parens with arrow functions - arrow-parens
• Maximum one statement per line, please - max-statements-per-line
• Maximum 10 statements per scope - max-statements
• No nested hell - maximum 5 nested callbacks (max-nested-callbacks) and depth (max-depth)
  • If that's your case, reogranize code, increase or disable with eslint style comments
• No extra semi - hence, we use style without any semicolons - no-extra-semi
• No empty blocks and statements - no-empty. But allowing empty catch (er) {}s
• Prefer destructing of arrays and objects when possible, because we're in 2017 - prefer-destructuring
• Prefer arrow block body only if needed - arrow-body-style, so
  • No () => { return { a: 1 } }, when you can just () => ({ a: 1 })
  • No () => { return 1 }, when () => 1 is enough

Badge

Since this is just thin layer on top of the Standard, I don't think we should release our own badge. But in another hand - we are a bit different, so preferebly just call it code style charlike.

So in case you use the charlike style in your projects or just want to support and promote it, then include this badge in your README file.

Code for the badge above:

<!-- somewhere at the top -->
[![code-style-charlike][charlike-img]][charlike-url]

<!-- somewhere at the bottom -->
[charlike-img]: https://img.shields.io/badge/code%20style-charlike-536dfe.svg
[charlike-url]: https://github.com/tunnckoCore/eslint-config-charlike

Install

Install with npm

$ npm install eslint-config-charlike --save

or install using yarn

$ yarn add eslint-config-charlike

Usage

This config is designed to work with the extends feature of eslint inside the .eslintrc files. You can learn more about Shareable Configs on the official ESLint website.

Install it then add this to your .eslintrc file:

{
  "extends": "charlike"
}

Note: We omitted the eslint-config- prefix since it is automatically assumed by ESLint. You can override settings from the shareable config by adding them directly into your .eslintrc file.

Related

• always-done: Handle completion and errors with elegance! Support for streams, callbacks, promises, child processes, async/await and sync functions. A drop-in replacement… more | homepage
• minibase: Minimalist alternative for Base. Build complex APIs with small units called plugins. Works well with most of the already existing… more | homepage
• try-catch-core: Low-level package to handle completion and errors of sync or asynchronous functions, using once and dezalgo libs. Useful for and… more | homepage

Contributing

Pull requests and stars are always welcome. For bugs and feature requests, please create an issue.
Please read the contributing guidelines for advice on opening issues, pull requests, and coding standards.
If you need some help and can spent some cash, feel free to contact me at CodeMentor.io too.

In short: If you want to contribute to that project, please follow these things

1. Please DO NOT edit README.md, CHANGELOG.md and .verb.md files. See "Building docs" section.
2. Ensure anything is okey by installing the dependencies and run the tests. See "Running tests" section.
3. Always use npm run commit to commit changes instead of git commit, because it is interactive and user-friendly. It uses commitizen behind the scenes, which follows Conventional Changelog idealogy.
4. Do NOT bump the version in package.json. For that we use npm run release, which is standard-version and follows Conventional Changelog idealogy.

Thanks a lot! :)

Building docs

Documentation and that readme is generated using verb-generate-readme, which is a verb generator, so you need to install both of them and then run verb command like that

$ npm install verbose/verb#dev verb-generate-readme --global && verb

Please don't edit the README directly. Any changes to the readme must be made in .verb.md.

Running tests

Clone repository and run the following in that cloned directory

$ npm install && npm test

Author

Charlike Mike Reagent

• github/tunnckoCore
• twitter/tunnckoCore
• codementor/tunnckoCore

License

Copyright © 2016-2017, Charlike Mike Reagent. MIT

This file was generated by verb-generate-readme, v0.4.2, on February 28, 2017.
Project scaffolded using charlike cli.