arijs/prettier-miscellaneous

Name: prettier-miscellaneous

Owner: AriJS

Description: Prettier is an opinionated JavaScript formatter.

Forked from: prettier/prettier

Created: 2017-01-17 17:04:48.0

Updated: 2018-01-17 00:13:03.0

Pushed: 2017-07-17 15:23:02.0

Homepage: https://jlongster.github.io/prettier/

Size: 15489

Language: JavaScript

GitHub Committers

UserMost Recent Commit# Commits

Other Committers

UserEmailMost Recent Commit# Commits

README

Prettier Miscellaneous

Gitter Build Status CircleCI Status Codecov NPM version styled with prettier

CONFIGURATION WELCOME

This is a fork of prettier/prettier, with a goal of supporting additional options not picked up by official Prettier.

If you want to add an option to Prettier Miscellaneous, please send a PR! ?

Happyness

Prettier is an opinionated code formatter with support for:

It removes all original styling* and ensures that all outputted code conforms to a consistent style. (See this blog post)

Table of Contents


What does Prettier do?

Prettier takes your code and reprints it from scratch by taking the line length into account.

For example, take the following code:

arg1, arg2, arg3, arg4);

It fits in a single line so it's going to stay as is. However, we've all run into this situation:

reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

Suddenly our previous format for calling function breaks down because this is too long. Prettier is going to do the painstaking work of reprinting it like that for you:


allyLongArg(),
gSoManyParameters(),
houldRefactorThis(),
ThereSeriouslyAnotherOne()

Prettier enforces a consistent code style (i.e. code formatting that won't affect the AST) across your entire codebase because it disregards the original styling* by parsing it away and re-printing the parsed AST with its own rules that take the maximum line length into account, wrapping code when necessary.

*Well actually, some original styling is preserved when practical?see empty lines and multi-line objects.

If you want to learn more, these two conference talks are great introductions:

Why Prettier?
Building and enforcing a style guide

By far the biggest reason for adopting Prettier is to stop all the on-going debates over styles. It is generally accepted that having a common style guide is valuable for a project and team but getting there is a very painful and unrewarding process. People get very emotional around particular ways of writing code and nobody likes spending time writing and receiving nits.

Helping Newcomers

Prettier is usually introduced by people with experience in the current codebase and JavaScript but the people that disproportionally benefit from it are newcomers to the codebase. One may think that it's only useful for people with very limited programming experience, but we've seen it quicken the ramp up time from experienced engineers joining the company, as they likely used a different coding style before, and developers coming from a different programming language.

Writing code

What usually happens once people are using Prettier is that they realize that they actually spend a lot of time and mental energy formatting their code. With Prettier editor integration, you can just press that magic key binding and poof, the code is formatted. This is an eye opening experience if anything else.

Easy to adopt

We've worked very hard to use the least controversial coding styles, went through many rounds of fixing all the edge cases and polished the getting started experience. When you're ready to push Prettier into your codebase, not only should it be painless for you to do it technically but the newly formatted codebase should not generate major controversy and be accepted painlessly by your co-workers.

Clean up an existing codebase

Since coming up with a coding style and enforcing it is a big undertaking, it often slips through the cracks and you are left working on inconsistent codebases. Running Prettier in this case is a quick win, the codebase is now uniform and easier to read without spending hardly any time.

Ride the hype train

Purely technical aspects of the projects aren't the only thing people look into when choosing to adopt Prettier. Who built and uses it and how quickly it spreads through the community has a non-trivial impact.

A few of the many projects using Prettier:

React
React

Jest
Jest

Yarn
Yarn

Babel
Babel

Zeit
Zeit

Webpack-cli
Webpack-cli

How does it compare to ESLint (or TSLint, stylelint…)?

Linters have two categories of rules:

Formatting rules: eg: max-len, no-mixed-spaces-and-tabs, keyword-spacing, comma-style

Prettier alleviates the need for this whole category of rules! Prettier is going to reprint the entire program from scratch in a consistent way, so it's not possible for the programmer to make a mistake there anymore :)

Code-quality rules: eg no-unused-vars, no-extra-bind, no-implicit-globals, prefer-promise-reject-errors

Prettier does nothing to help with those kind of rules. They are also the most important ones provided by linters as they are likely to catch real bugs with your code!

Usage

Install:

 add prettier-miscellaneous --dev

You can install it globally if you like:

 global add prettier-miscellaneous

We're using yarn but you can use npm if you like:

install [--save-dev|--global] prettier-miscellaneous
CLI

Run Prettier through the CLI with this script. Run it without any arguments to see the options.

To format a file in-place, use --write. You may want to consider committing your code before doing that, just in case.

tier [opts] [filename ...]

In practice, this may look something like:

tier --single-quote --trailing-comma es5 --write "{app,__{tests,mocks}__}/**/*.js"

Don't forget the quotes around the globs! The quotes make sure that Prettier expands the globs rather than your shell, for cross-platform usage. The glob syntax from the glob module is used.

--with-node-modules

Prettier CLI will ignore files located in node_modules directory. To opt-out from this behavior use --with-node-modules flag.

--list-different

Another useful flag is --list-different (or -l) which prints the filenames of files that are different from Prettier formatting. If there are differences the script errors out, which is useful in a CI scenario.

tier --single-quote --list-different "src/**/*.js"
--find-config-path and --config

If you are repeatedly formatting individual files with prettier, you will incur a small performance cost when prettier attempts to look up a configuration file. In order to skip this, you may ask prettier to find the config file once, and re-use it later on.

tier --find-config-path ./my/file.js
/.prettierrc

This will provide you with a path to the configuration file, which you can pass to --config:

tier --config ./my/.prettierrc --write ./my/file.js

You can also use --config if your configuration file lives somewhere where prettier cannot find it, such as a config/ directory.

If you don't have a configuration file, or want to ignore it if it does exist, you can pass --no-config instead.

--debug-check

If you're worried that Prettier will change the correctness of your code, add --debug-check to the command. This will cause Prettier to print an error message if it detects that code correctness might have changed. Note that --write cannot be used with --debug-check.

ESLint

If you are using ESLint, integrating Prettier to your workflow is straightforward:

Just add Prettier as an ESLint rule using eslint-plugin-prettier.

 add --dev prettier eslint-plugin-prettier

eslintrc

lugins": [
"prettier"

ules": {
"prettier/prettier": "error"


We also recommend that you use eslint-config-prettier to disable all the existing formatting rules. It's a one liner that can be added on-top of any existing ESLint configuration.

rn add --dev eslint-config-prettier

.eslintrc.json:


xtends": [
"prettier"


Pre-commit Hook

You can use Prettier with a pre-commit tool. This can re-format your files that are marked as “staged” via git add before you commit.

Option 1. lint-staged

Install it along with husky:

 add lint-staged husky --dev

and add this config to your package.json:


cripts": {
"precommit": "lint-staged"

int-staged": {
"*.js": [
  "prettier --write",
  "git add"
]


See https://github.com/okonet/lint-staged#configuration for more details about how you can configure lint-staged.

Option 2. pre-commit

Copy the following config into your .pre-commit-config.yaml file:

-   repo: https://github.com/prettier/prettier
    sha: ''  # Use the sha or tag you want to point at
    hooks:
    -   id: prettier

Find more info from here.

Option 3. bash script

Alternately you can save this script as .git/hooks/pre-commit and give it execute permission:

in/sh
les=$(git diff --cached --name-only --diff-filter=ACM | grep '\.jsx\?$' | tr '\n' ' ')
 "$jsfiles" ] && exit 0

ettify all staged .js files
 "$jsfiles" | xargs ./node_modules/.bin/prettier --write

d back the modified/prettified files to staging
 "$jsfiles" | xargs git add

 0
Options

Prettier ships with a handful of customizable format options, usable in both the CLI and API.

| Option | Default | Override | | —— | ——- | ——– | | Print Width - Specify the length of line that the printer will wrap on.

We strongly recommend against using more than 80 columns. Prettier works by cramming as much content as possible until it reaches the limit, which happens to work well for 80 columns but makes lines that are very crowded. When a bigger column count is used in styleguides, it usually means that code is allowed to go beyond 80 columns, but not to make every single line go there, like prettier would do. | 80 | CLI: --print-width <int>
API: printWidth: <int> | Tab Width - Specify the number of spaces per indentation-level. | 2 | CLI: --tab-width <int>
API: tabWidth: <int> | | Tabs - Indent lines with tabs instead of spaces. | false | CLI: --use-tabs
API: useTabs: <bool> | | Semicolons - Print semicolons at the ends of statements.

Valid options:

| true | CLI: --no-semi
API: semi: <bool> | | Quotes - Use single quotes instead of double quotes.

Notes: | false | CLI: --single-quote
API: singleQuote: <bool> | | JSX Single Quote - Use single quotes instead of double quotes for JSX attributes. | false | CLI: --jsx-single-quote
API: jsxSingleQuote: <bool> | | Trailing Commas - Print trailing commas wherever possible.

Valid options: | "none" | CLI: –trailing-comma
API: trailingComma: “ | | Trailing Commas (extended) - You can also customize each place to use trailing commas:

Valid options:
- "array"
- "object"
- "import"
- "export"
- "arguments" | "none" | You can use a comma separated string list, or an object in the API.

CLI: –trailing-comma “array,object,import,export,arguments”
API: trailingComma: { array: true, object: true, import: true, export: true, arguments: false } | | Bracket Spacing - Print spaces between brackets in array literals.

Valid options:
- true - Example: [ foo: bar ]
- false - Example: [foo: bar] | true | CLI: --no-bracket-spacing
API: bracketSpacing: <bool> | | Braces Spacing - Print spaces between braces in object literals.

Valid options:

This work is supported by the National Institutes of Health's National Center for Advancing Translational Sciences, Grant Number U24TR002306. This work is solely the responsibility of the creators and does not necessarily represent the official views of the National Institutes of Health.