npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

prettier-miscellaneous

v1.5.3

Published

Prettier Miscellaneous is a fork of Prettier with the goal of supporting minor extra options

Downloads

8,145

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)


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:

foo(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:

foo(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:

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

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.

  • “We want to free mental threads and end discussions around style. While sometimes fruitful, these discussions are for the most part wasteful.”
  • “Literally had an engineer go through a huge effort of cleaning up all of our code because we were debating ternary style for the longest time and were inconsistent about it. It was dumb, but it was a weird on-going "great debate" that wasted lots of little back and forth bits. It's far easier for us all to agree now: just run Prettier, and go with that style.”
  • “Getting tired telling people how to style their product code.”
  • “Our top reason was to stop wasting our time debating style nits.”
  • “Having a githook set up has reduced the amount of style issues in PRs that result in broken builds due to ESLint rules or things I have to nit-pick or clean up later.”
  • “I don't want anybody to nitpick any other person ever again.”
  • “It reminds me of how Steve Jobs used to wear the same clothes every day because he has a million decisions to make and he didn't want to be bothered to make trivial ones like picking out clothes. I think Prettier is like that.”

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.

  • “My motivations for using Prettier are: appearing that I know how to write JavaScript well.”
  • “I always put spaces in the wrong place, now I don't have to worry about it anymore.”
  • “When you're a beginner you're making a lot of mistakes caused by the syntax. Thanks to Prettier, you can reduce these mistakes and save a lot of time to focus on what really matters.”
  • “As a teacher, I will also tell to my students to install Prettier to help them to learn the JS syntax and have readable files.”

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.

  • “I want to write code. Not spend cycles on formatting.”
  • “It removed 5% that sucks in our daily life - aka formatting”
  • “We're in 2017 and it's still painful to break a call into multiple lines when you happen to add an argument that makes it go over the 80 columns limit :(“

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.

  • “It's low overhead. We were able to throw Prettier at very different kinds of repos without much work.”
  • “It's been mostly bug free. Had there been major styling issues during the course of implementation we would have been wary about throwing this at our JS codebase. I'm happy to say that's not the case.”
  • “Everyone runs it as part of their pre commit scripts, a couple of us use the editor on save extensions as well.”
  • “It's fast, against one of our larger JS codebases we were able to run Prettier in under 13 seconds.”
  • “The biggest benefit for Prettier for us was being able to format the entire code base at once.”

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.

  • “Take a look at the code :) I just need to restore sanity.”
  • “We inherited a ~2000 module ES6 code base, developed by 20 different developers over 18 months, in a global team. Felt like such a win without much research.

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.

  • “The amazing thing, for me, is: 1) Announced 2 months ago. 2) Already adopted by, it seems, every major JS project. 3) 7000 stars, 100,000 npm downloads/mo”
  • “Was built by the same people as React & React Native.”
  • “I like to be part of the hot new things.”
  • “Because soon enough people are gonna ask for it.”

A few of the many projects using Prettier:

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:

yarn add prettier-miscellaneous --dev

You can install it globally if you like:

yarn global add prettier-miscellaneous

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

npm 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.

prettier [opts] [filename ...]

In practice, this may look something like:

prettier --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.

prettier --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.

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

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

prettier --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.

yarn add --dev prettier eslint-plugin-prettier

// .eslintrc
{
  "plugins": [
    "prettier"
  ],
  "rules": {
    "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.

$ yarn add --dev eslint-config-prettier

.eslintrc.json:

{
  "extends": [
    "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:

yarn add lint-staged husky --dev

and add this config to your package.json:

{
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-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:

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

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

# Add back the modified/prettified files to staging
echo "$jsfiles" | xargs git add

exit 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 - add a semicolon at the end of every statementfalse - only add semicolons at the beginning of lines that may introduce ASI failures | true | CLI: --no-semi API: semi: <bool> | | Quotes - Use single quotes instead of double quotes.Notes:Quotes in JSX will always be double and ignore this setting, unless --jsx-single-quote is used.If the number of quotes outweighs the other quote, the quote which is less used will be used to format the string - Example: "I'm double quoted" results in "I'm double quoted" and "This \"example\" is single quoted" results in 'This "example" is single quoted'. | 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" - no trailing commas "es5" - trailing commas where valid in ES5 (objects, arrays, etc.)"all" - trailing commas wherever possible (function arguments). This requires node 8 or a transform. | "none" | CLI: --trailing-comma <none|es5|all> API: trailingComma: "<none|es5|all>" | | 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: true - Example: { foo: bar }false - Example: {foo: bar} | true | CLI: --no-braces-spacing API: bracesSpacing: <bool> | | JSX Brackets on Same Line - Put the > of a multi-line JSX element at the end of the last line instead of being alone on the next line | false | CLI: --jsx-bracket-same-line API: jsxBracketSameLine: <bool> | | Align Object Properties - Align colons in multiline object literals. Does nothing if object has computed property names. | false | CLI: --align-object-properties API: alignObjectProperties: <bool> | | No Space in Empty Function - Omit space before empty anonymous function body.Valid options: - true - false | false | CLI: --no-space-empty-fn API: noSpaceEmptyFn: <bool> | | Space before Function Paren - Put a space before function parenthesis.Valid options: - true - false | false | CLI: --space-before-function-paren API: spaceBeforeFunctionParen: <bool> | | Cursor Offset - Specify where the cursor is. This option only works with prettier.formatWithCursor, and cannot be used with rangeStart and rangeEnd. | -1 | CLI: --cursor-offset <int> API: cursorOffset: <int> | | Range Start - Format code starting at a given character offset. The range will extend backwards to the start of the first line containing the selected statement. This option cannot be used with cursorOffset. | 0 | CLI: --range-start <int> API: rangeStart: <int> | | Range End - Format code ending at a given character offset (exclusive). The range will extend forwards to the end of the selected statement. This option cannot be used with cursorOffset. | Infinity | CLI: --range-end <int> API: rangeEnd: <int> | | Parser - Specify which parser to use. Both the babylon and flow parsers support the same set of JavaScript features (including Flow). Prettier automatically infers the parser from the input file path, so you shouldn't have to change this setting. Built-in parsers: babylonflowtypescriptpostcssjsonCustom parsers are also supported. | babylon | CLI: --parser <string> --parser ./path/to/my-parser API: parser: "<string>" parser: require("./my-parser") | | Filepath - Specify the input filepath this will be used to do parser inference. Example: cat foo \| prettier --stdin-filepath foo.css will default to use postcss parser | | CLI: --stdin-filepath API: filepath: "<string>" |

API

const prettier = require("prettier-miscellaneous");

prettier.format(source [, options])

format is used to format text using Prettier. Options may be provided to override the defaults.

prettier.format("foo ( );", { semi: false });
// -> "foo()"

prettier.check(source [, options])

check checks to see if the file has been formatted with Prettier given those options and returns a Boolean. This is similar to the --list-different parameter in the CLI and is useful for running Prettier in CI scenarios.

prettier.formatWithCursor(source [, options])

formatWithCursor both formats the code, and translates a cursor position from unformatted code to formatted code. This is useful for editor integrations, to prevent the cursor from moving when code is formatted.

The cursorOffset option should be provided, to specify where the cursor is. This option cannot be used with rangeStart and rangeEnd.

prettier.formatWithCursor(" 1", { cursorOffset: 2 });
// -> { formatted: '1;\n', cursorOffset: 1 }

prettier.resolveConfig([filePath] [, options])

resolveConfig can be used to resolve configuration for a given source file. The function optionally accepts an input file path as an argument, which defaults to the current working directory. A promise is returned which will resolve to:

  • An options object, providing a config file was found.
  • null, if no file was found.

The promise will be rejected if there was an error parsing the configuration file.

If options.withCache is false, all caching will be bypassed.

const text = fs.readFileSync(filePath, "utf8");
prettier.resolveConfig(filePath).then(options => {
  const formatted = prettier.format(text, options);
})

prettier.clearConfigCache()

As you repeatedly call resolveConfig, the file system structure will be cached for performance. This function will clear the cache. Generally this is only needed for editor integrations that know that the file system has changed since the last format took place.

Custom Parser API

If you need to make modifications to the AST (such as codemods), or you want to provide an alternate parser, you can do so by setting the parser option to a function. The function signature of the parser function is:

(text: string, parsers: object, options: object) => AST;

Prettier's built-in parsers are exposed as properties on the parsers argument.

prettier.format("lodash ( )", {
  parser(text, { babylon }) {
    const ast = babylon(text);
    ast.program.body[0].expression.callee.name = "_";
    return ast;
  }
});
// -> "_();\n"

The --parser CLI option may be a path to a node.js module exporting a parse function.

Excluding code from formatting

A JavaScript comment of // prettier-ignore will exclude the next node in the abstract syntax tree from formatting.

For example:

matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
)

// prettier-ignore
matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
)

will be transformed to:

matrix(1, 0, 0, 0, 1, 0, 0, 0, 1);

// prettier-ignore
matrix(
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
)

Options

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

Print Width

Specify the line length that the printer will wrap on.

For readability we recommend against using more than 80 characters:

In code styleguides, maximum line length rules are often set to 100 or 120. However, when humans write code, they don't strive to reach the maximum number of columns on every line. Developers often use whitespace to break up long lines for readability. In practice, the average line length often ends up well below the maximum.

Prettier, on the other hand, strives to fit the most code into every line. With the print width set to 120, prettier may produce overly compact, or otherwise undesirable code.

Default | CLI Override | API Override --------|--------------|------------- 80 | --print-width <int> | printWidth: <int>

Tab Width

Specify the number of spaces per indentation-level.

Default | CLI Override | API Override --------|--------------|------------- 2 | --tab-width <int> | tabWidth: <int>

Tabs

Indent lines with tabs instead of spaces

Default | CLI Override | API Override --------|--------------|------------- false | --use-tabs | useTabs: <bool>

Semicolons

Print semicolons at the ends of statements.

Valid options:

  • true - Add a semicolon at the end of every statement.
  • false - Only add semicolons at the beginning of lines that may introduce ASI failures.

Default | CLI Override | API Override --------|--------------|------------- true | --no-semi | semi: <bool>

Quotes

Use single quotes instead of double quotes.

Notes:

  • Quotes in JSX will always be double and ignore this setting.
  • If the number of quotes outweighs the other quote, the quote which is less used will be used to format the string - Example: "I'm double quoted" results in "I'm double quoted" and "This \"example\" is single quoted" results in 'This "example" is single quoted'.

Default | CLI Override | API Override --------|--------------|------------- false | --single-quote | singleQuote: <bool>

Trailing Commas

Print trailing commas wherever possible.

Valid options:

  • "none" - No trailing commas.
  • "es5" - Trailing commas where valid in ES5 (objects, arrays, etc.)
  • "all" - Trailing commas wherever possible (function arguments). This requires node 8 or a transform.

Default | CLI Override | API Override --------|--------------|------------- "none" | --trailing-comma <none|es5|all> | trailingComma: "<none|es5|all>"

Bracket Spacing

Print spaces between brackets in object literals.

Valid options:

  • true - Example: { foo: bar }.
  • false - Example: {foo: bar}.

Default | CLI Override | API Override --------|--------------|------------- true | --no-bracket-spacing | bracketSpacing: <bool>

JSX Brackets

Put the > of a multi-line JSX element at the end of the last line instead of being alone on the next line.

Default | CLI Override | API Override --------|--------------|------------- false | --jsx-bracket-same-line | jsxBracketSameLine: <bool>

Range

Format only a segment of a file.

These two options can be used to format code starting and ending at a given character offset (inclusive and exclusive, respectively). The range will extend:

  • Backwards to the start of the first line containing the selected statement.
  • Forwards to the end of the selected statement.

These options cannot be used with cursorOffset.

Default | CLI Override | API Override --------|--------------|------------- 0 | --range-start <int>| rangeStart: <int> Infinity | --range-end <int> | rangeEnd: <int>

Parser

Specify which parser to use.

Both the babylon and flow parsers support the same set of JavaScript features (including Flow). Prettier automatically infers the parser from the input file path, so you shouldn't have to change this setting.

Built-in parsers:

Custom parsers are also supported. Since v1.5.0

Default | CLI Override | API Override --------|--------------|------------- babylon | --parser <string>--parser ./my-parser | parser: "<string>"parser: require("./my-parser")

Filepath

Specify the input filepath. This will be used to do parser inference.

For example, the following will use postcss parser:

cat foo | prettier --stdin-filepath foo.css

Default | CLI Override | API Override --------|--------------|------------- None | --stdin-filepath <string> | filepath: "<string>"

Configuration File

Prettier uses cosmiconfig for configuration file support. This means you can configure prettier via:

  • A .prettierrc file, written in YAML or JSON.
  • A prettier.config.js file that exports an object.
  • A "prettier" key in your package.json file.

The configuration file will be resolved starting from the location of the file being formatted, and searching up the file tree until a config file is (or isn't) found.

The options to the configuration file are the same the API options.

Basic Configuration

JSON:

// .prettierrc
{
  "printWidth": 100,
  "parser": "flow"
}

YAML:

# .prettierrc
printWidth: 100
parser: flow

Configuration Overrides

Prettier borrows eslint's override format. This allows you to apply configuration to specific files.

JSON:

{
  "semi": false,
  "overrides": [{
    "files": "*.test.js",
    "options": {
      "semi": true
    }
  }]
}

YAML:

semi: false
overrides:
- files: "*.test.js"
  options:
    semi: true

files is required for each override, and may be a string or array of strings. excludeFiles may be optionally provided to exclude files for a given rule, and may also be a string or array of strings.

To get prettier to format its own .prettierrc file, you can do:

{
  "overrides": [{
    "files": ".prettierrc",
    "options": { "parser": "json" }
  }]
}

For more information on how to use the CLI to locate a file, see the CLI section.

Configuration Schema

If you'd like a JSON schema to validate your configuration, one is available here: http://json.schemastore.org/prettierrc.

Editor Integration

Atom

Atom users can simply install the prettier-atom-with-tabs package and use Ctrl+Alt+F to format a file (or format on save if enabled).

Emacs

Emacs users should see this repository for on-demand formatting.

Vim

Vim users can simply install either sbdchd/neoformat, w0rp/ale, or mitermayer/vim-prettier, for more details see this directory.

Visual Studio Code

Can be installed using the extension sidebar. Search for Prettier - JavaScript formatter.

Can also be installed using ext install prettier-vscode-with-tabs

Check its repository for configuration and shortcuts

Visual Studio

Install the JavaScript Prettier extension.

Sublime Text

Sublime Text support is available through Package Control and the JsPrettier plug-in.

JetBrains WebStorm, PHPStorm, PyCharm...

See the WebStorm guide.

Language Support

Prettier attempts to support all JavaScript language features, including non-standardized ones. By default it uses the Babylon parser with all language features enabled, but you can also use the Flow parser with the parser API or --parser CLI option.

All of JSX and Flow syntax is supported. In fact, the test suite in tests is the entire Flow test suite and they all pass.

Prettier also supports TypeScript, CSS, LESS, SCSS, JSON, and GraphQL.

The minimum version of TypeScript supported is 2.1.3 as it introduces the ability to have leading | for type definitions which prettier outputs.

Related Projects

Technical Details

This printer is a fork of recast's printer with its algorithm replaced by the one described by Wadler in "A prettier printer". There still may be leftover code from recast that needs to be cleaned up.

The basic idea is that the printer takes an AST and returns an intermediate representation of the output, and the printer uses that to generate a string. The advantage is that the printer can "measure" the IR and see if the output is going to fit on a line, and break if not.

This means that most of the logic of printing an AST involves generating an abstract representation of the output involving certain commands. For example, concat(["(", line, arg, line ")"]) would represent a concatenation of opening parens, an argument, and closing parens. But if that doesn't fit on one line, the printer can break where line is specified.

More (rough) details can be found in commands.md.

Badge

Show the world you're using Prettierstyled with prettier

[![styled with prettier](https://img.shields.io/badge/styled_with-prettier-ff69b4.svg)](https://github.com/prettier/prettier)

Contributing

See CONTRIBUTING.md.