Related Pages

Related topics: Language Support & Plugin Architecture, Configuration Philosophy & Options

Overview & Internal Architecture

Prettier is an "opinionated code formatter" that enforces a consistent style by parsing source code into an Abstract Syntax Tree (AST) and re-printing it using its own rules, wrapping code as needed to honor a maximum line length (README.md:1-15).

The repository at <https://github.com/prettier/prettier> is structured as a monorepo: a single root prettier package that ships the core formatter, plus a packages/ directory that hosts separately published plugins such as @prettier/plugin-hermes. The website at <https://prettier.io> lives in website/ and is built with Docusaurus (website/README.md:1-50).

Purpose and Scope

Prettier's stated purpose is to remove bikeshedding from code review by formatting code automatically on save, in pre-commit hooks, or in CI. The README frames it as a tool that "ensures your codebase has a consistent style without devs ever having to post a nit-picky comment on a code review ever again" (README.md:45-50).

The project intentionally keeps its option surface small. This is a deliberate design stance maintained by the team; the long-running issue #40, "Resist adding configuration", argues against letting the option set grow without bound. As a result, the documented CLI flags and configuration options are tightly curated.

Supported languages span JavaScript, TypeScript, Flow, JSX, JSON, CSS, SCSS, Less, HTML, Vue, Angular, GraphQL, Markdown, and YAML, with extensions available through plugins (README.md:25-40).

Repository Layout

The repository is organized into the following top-level areas:

The root package.json declares "type": "module", requires Node.js >=22, and exposes the package through a conditional exports map that distinguishes between import, require, browser, and standalone bundles (package.json:1-60). The bin field points to ./bin/prettier.cjs, so the prettier command on a user's PATH resolves to that launcher.

The #universal subpath imports with the imports field route to browser-specific implementations in src/universal/*.browser.js when bundled for the browser and to the default src/universal/*.js in Node (package.json:20-35). This is what powers the in-browser Playground.

Plugin Architecture

Plugins are first-class. The exports field advertises ./plugins/* so consumers can resolve plugin entry points by name (package.json:36-45). Plugins are typically installed as separate npm packages and registered through a Prettier configuration file.

@prettier/plugin-hermes is a representative example. Its package.json lives under packages/plugin-hermes/, is published as its own npm package, and uses "type": "module" with index.mjs as the default entry and index.d.ts for TypeScript declarations (packages/plugin-hermes/package.json:1-20). The plugin README instructs users to add it to the plugins array of a Prettier config, or to wire it into specific files via overrides keyed on the hermes parser (packages/plugin-hermes/README.md:1-50).

Language Pipeline (JavaScript / TypeScript Family)

Inside src/language-js/, each AST node type has a dedicated printer. The printers consume Doc builders from ../../document/ and stitch them together with constructs such as group, indent, line, softline, hardline, and ifBreak (see src/language-js/print/mapped-type.js:1-60 and src/language-js/print/miscellaneous.js:1-15).

For binary/logical expressions and Angular pipes, printBinaryishExpression in src/language-js/print/binaryish.js:1-30 detects the surrounding context (e.g., inside if, while, switch, do/while) to decide whether the expression should be parenthesized. Helpers such as hasLeadingOwnLineComment and isBooleanTypeCoercion keep the wrapping decisions stable across runs.

For JSDoc-style nullable/non-nullable types, printJSDocType chooses between prefix and postfix token placement based on node.postfix, delegating the inner annotation to printTypeAnnotationProperty (src/language-js/print/js-doc-type.js:1-10). This pattern — small, focused printers per node type — is repeated across src/language-js/print/, and similar printer trees exist under src/language-css/, src/language-markdown/, src/language-graphql/, etc.

CLI Surface

The CLI is declared declaratively in src/cli/cli-options.evaluate.js. Each option entry has a category (such as CATEGORY_CONFIG or CATEGORY_OUTPUT), a type (for example boolean, path, flag), an optional alias (e.g., --help/-h, --list-different/-l), a default, and a human-readable description. Path-valued options like ignorePath accept arrays and default to [".gitignore", ".prettierignore"]. This schema-driven approach is what makes prettier --help <flag> work uniformly across every option.

Data Flow

flowchart LR
    Source[Source text] --> Parse[Language plugin parser]
    Parse --> AST[AST]
    AST --> Attach[Comment attachment]
    Attach --> Print[Per-node printers]
    Print --> Doc[Doc IR]
    Doc --> Format[Doc printer & line breaker]
    Format --> Output[Formatted text]

Each language plugin owns the parser step; the rest of the pipeline (AST → Doc → output) is shared across languages. The Doc IR is the abstraction that lets the same printer backend handle line wrapping consistently for every language, and it is what makes Prettier's output stable regardless of which parser produced the AST.

Configuration and Option Philosophy

Prettier ships with a deliberately small set of options. Decisions about defaults (such as tabs vs. spaces, tracked in issue #7475) and about which formatting choices should be configurable at all (#40) are made on the project's own terms rather than by committee. The README and the docs/ directory are the canonical references for the supported option set; anything not listed there is intentionally outside scope.

Common Failure Modes

A few recurring sources of friction show up in the issue tracker:

• List-item edge cases in Markdown. Ordered-list markers are limited to nine digits because of browser integer-overflow risks (spec.commonmark.org/0.31.2/#ordered-list-marker). The formatter preserves the original marker length rather than expanding it, which can surprise users who expected numeric normalization.
• Markdown blank lines between sub-lists. Lost blank lines between nested list items were a regression addressed in 3.8.4 (release notes).
• Configuration drift. Because adding options is resisted by design, requests to expose new knobs (e.g., operator placement, ternary indentation, anonymous function spacing) often close without action. Users who need non-default behavior typically reach for a plugin or a wrapper script rather than a core option.
• Plugin compatibility. Plugins declare a minimum Prettier version (e.g., @prettier/plugin-hermes requires prettier>=3.6.0 per its README). Mismatched majors between core and plugin can manifest as missing parsers or printers at runtime.

See Also

• CLI Options Reference
• Plugin: @prettier/plugin-hermes
• Documentation Site Guide
• Project README

Related Pages

Related topics: Overview & Internal Architecture, Configuration Philosophy & Options

Language Support & Plugin Architecture

Overview

Prettier is an opinionated code formatter that ships with parsers and printers for a broad set of languages and extends its reach through a plugin protocol. The package.json declares Prettier as an ES module ("type": "module") and exposes the public API through both CommonJS and ESM entry points, with a dedicated ./plugins/* subpath export for plugin discovery Source: package.json:5-25. The README frames the project around "few options" and an opinionated default, which is the design constraint that the language and plugin modules must respect Source: README.md:1-40.

The shipped distribution currently targets Node.js 22 and newer ("engines": { "node": ">=22" }), which matters for plugin authors because language modules can rely on modern Node APIs without polyfills Source: package.json:28-30.

Built-in Language Modules

Each supported language lives under src/language-<name>/ and exports a parsers, printers, and (optionally) embedded-language configuration. The following directories make up the in-tree language matrix:

Recent changelog entries show this matrix evolves continually: 3.8.0 added Angular v21.1 support, 3.8.2 added Angular v21.2, and 3.8.4 fixed Markdown blank lines between nested list items — demonstrating the per-language maintenance cadence Source: README.md:1-40, package.json:54-80.

Plugin Architecture

The plugin system is the primary extension point for languages Prettier does not ship with. Plugins are regular npm packages that export a Prettier-compatible module; they are loaded through the ./plugins/* subpath export, which lets Prettier resolve plugin files by name Source: package.json:15-25.

The @prettier/plugin-hermes package is a representative example. Its package.json declares an ESM-only entry, the appropriate repository metadata, and sideEffects: false so it can be tree-shaken by bundlers Source: packages/plugin-hermes/package.json:1-25. The README documents two configuration patterns:

// prettier.config.mjs
import * as prettierPluginHermes from "@prettier/plugin-hermes";

/** @type {import("prettier").Config} */
const config = {
  plugins: [prettierPluginHermes],
};

export default config;

or, more selectively, scoped to specific file patterns via overrides:

const config = {
  overrides: [
    {
      files: ["**/*.{js.flow,js,mjs,cjs}"],
      parser: "hermes",
      plugins: [prettierPluginHermes],
    },
  ],
};

Source: packages/plugin-hermes/README.md:1-50.

The overrides mechanism is the recommended way to map plugins to file globs, while the top-level plugins array makes a parser available everywhere. Both patterns are validated through the same Prettier config loader.

Plugin Loading Flow

flowchart LR
    A[CLI / API call] --> B[Resolve config]
    B --> C{plugins array?}
    C -- yes --> D[Import each plugin module]
    C -- no --> E[Skip plugin step]
    D --> F[Merge parsers/printers]
    F --> G[Infer parser per file]
    G --> H[Run printer for chosen parser]

Source: package.json:15-25, packages/plugin-hermes/README.md:1-50, src/cli/cli-options.evaluate.js:1-60.

Configuration and Common Failure Modes

The CLI exposes knobs that interact with plugin selection, including ignoreUnknown (silently skip files Prettier cannot identify), ignorePath, and withNodeModules. The editorconfig flag lets configuration values flow from .editorconfig files; this matters because some projects use editorconfig instead of a Prettier config Source: src/cli/cli-options.evaluate.js:1-60.

Community evidence highlights recurring failure modes worth knowing about:

• Plugin scope and overrides — using overrides with files globs is the safest way to keep a plugin (such as plugin-hermes) from claiming the wrong extensions, especially in mixed-language repositories Source: packages/plugin-hermes/README.md:30-50.
• Opinionated defaults — the long-running "Resist adding configuration" thread (issue #40) reinforces that new language or plugin options are weighed against the few-options philosophy, so users should expect most behavior to be fixed and not flag-controlled Source: README.md:1-40, packages/plugin-hermes/README.md:1-50.
• Parser-specific bugs — per-language issues (Markdown ordered lists, SCSS if() trailing commas, Angular template versions, GraphQL 17 compatibility) are routinely fixed in patch releases; users on edge versions should pin Prettier with --exact as the Hermes plugin README recommends Source: packages/plugin-hermes/README.md:11-15, package.json:54-80.

See Also

• Prettier installation and CLI
• Configuration file format
• Creating a Prettier plugin

Related Pages

Related topics: Overview & Internal Architecture, CLI, Programmatic API & Tooling Integrations

Configuration Philosophy & Options

The Opinionated Formatter

Prettier describes itself as an "opinionated code formatter" that enforces a consistent style by parsing code and re-printing it under its own rules, wrapping lines when they exceed printWidth (README.md:1-3). The word "opinionated" is deliberate: rather than expose dozens of style toggles, the project intentionally narrows the configuration surface so that the formatter produces the same output regardless of who runs it.

This stance is articulated in docs/option-philosophy.md and reinforced by community discussion in issue #40 "Resist adding configuration", which frames every new option as a small contribution to a "tragedy of the commons" — each option may seem harmless in isolation, but cumulatively they erode the project’s core value of consistent, discussion-free output.

The package itself ships with this stance baked into its package.json:

{
  "name": "prettier",
  "version": "3.9.0-dev",
  "description": "Prettier is an opinionated code formatter"
}

Source: package.json:2-4. Note that version is 3.9.0-dev, aligning with the in-progress Release v3.9 milestone referenced in issue #19332.

Option Categories & Architecture

Prettier organizes its options into distinct buckets. The CLI layer groups flags using categories defined in src/cli/cli-options.evaluate.js. Two prominent categories visible in the source are:

Source: src/cli/cli-options.evaluate.js

Other layers of the option system include:

• Core options — defined in src/main/core-options.evaluate.js; affect printing fundamentals such as printWidth, tabWidth, and useTabs.
• Common options — defined in src/common/common-options.evaluate.js; shared behavior such as parsers and file handling.
• CLI options — defined in src/cli/cli-options.evaluate.js; flag-only behavior such as --check, --write, --list-different, and editor tooling.

flowchart LR
  A[User CLI flag or config file] --> B[CLI Option Definitions<br/>cli-options.evaluate.js]
  B --> C{Configuration?}
  C -- "CATEGORY_CONFIG" --> D[findConfigPath<br/>ignorePath]
  C -- "CATEGORY_OUTPUT" --> E[write<br/>listDifferent<br/>check]
  D --> F[Core Options<br/>core-options.evaluate.js]
  E --> F
  F --> G[Common Options<br/>common-options.evaluate.js]
  G --> H[Language Plugin]
  H --> I[Formatted Output]

This layered design lets the CLI, programmatic API, and editor integrations all consume the same option set without duplicating definitions.

Notable CLI Options

From src/cli/cli-options.evaluate.js, several CLI-only options illustrate the philosophy in action:

• fileInfo — "Extract the following info (as JSON) for a given file path. Reported fields: ignored (boolean), inferredParser (string | null)." Used by editor integrations to discover Prettier’s view of a file before formatting.
• findConfigPath — "Find and print the path to a configuration file for the given input file." Category: CATEGORY_CONFIG.
• ignorePath — Accepts multiple values; defaults to [".gitignore", ".prettierignore"]. Source: src/cli/cli-options.evaluate.js
• ignoreUnknown — Boolean flag (-u) to silently skip files Prettier does not know how to format.
• listDifferent — -l; prints only the names of files that would change. Tied to CATEGORY_OUTPUT.
• help — -h; supports --help write for details about a specific flag.
• errorOnUnmatchedPattern — Opposite of the "no errors on unmatched patterns" default, useful for strict CI runs.

These options deliberately concern workflow (where to look, what to skip, what to print), not aesthetics (how many spaces, which quote style, where to break lines). Aesthetics are absorbed into the core options so the formatter behaves identically everywhere.

Recurring Community Debates

The most-engaged issues in the repository’s history consistently revolve around option requests. Their longevity shows the tension between user preferences and Prettier’s commitment to opinionated defaults:

• Issue #40 — Resist adding configuration (41 comments): the canonical thread explaining why each request is evaluated against the broader cost of configurability.
• Issue #7475 — Change useTabs to true by default (661 comments): a multi-year argument about tabs vs. spaces, ultimately an options question.
• Issue #5814 — Nested ternary formatting (232 comments): requests to add an indent knob for nested ternaries.
• Issue #3806 — Placing operators at the beginning of lines (169 comments): an option to flip binary-operator line-break style.
• Issue #3847 — Space after function keyword (146 comments): requests to control whitespace in anonymous function expressions.

Even when these debates conclude without adding an option, the discussions are typically referenced in docs/option-philosophy.md as evidence for the project's restraint.

Failure Modes & Edge-Case Options

Some options exist specifically because the formatter’s defaults break user expectations in narrow cases:

• Disable trailing newline at EOF — issue #6360 is the long-running discussion. Because Prettier always emits a final newline for POSIX-conformant files, no escape hatch is provided; the workaround is post-processing.
• --prose-wrap preserve for Markdown — issue #13634 shows that the prose-wrap mode can re-interpret paragraphs as headings, an interaction between Markdown heuristics and the proseWrap option.
• Ordered list marker length — issue #19339 and issue #17778 demonstrate numeric precision limits inherited from the JavaScript Number type when formatters encounter 10+ digit ordered list markers, producing exponential-notation output.

These cases illustrate that "few options" does not mean "no surprises": behavior emerges from interaction between parser internals and the small set of exposed toggles.

See Also

• CLI documentation
• Configuration file formats
• Ignoring files
• Plugins
• Why Prettier?

Related Pages

Related topics: Overview & Internal Architecture, Configuration Philosophy & Options, Language Support & Plugin Architecture

CLI, Programmatic API & Tooling Integrations

Overview

Prettier exposes its formatting engine through three complementary surfaces: a command-line binary for shell and CI usage, a programmatic API for embedding Prettier inside other Node.js tools, and a plugin/integration ecosystem that extends both surfaces. The prettier package declares the binary at ./bin/prettier.cjs and ships a main/ESM dual export for programmatic consumers, while the website documents the supported editors and showcases the wider user base Source: [package.json:6-21]().

The README frames Prettier as an "opinionated code formatter" that "enforces a consistent style by parsing your code and re-printing it with its own rules" — that core loop (parse → IR → print) is what every entry point ultimately calls into Source: [README.md:23-30]().

CLI Surface

Binary and package shape

The published package declares:

Source: package.json:5-31

Option categories

The CLI's option schema is centralized in src/cli/cli-options.evaluate.js. Options are grouped by category (e.g. CATEGORY_CONFIG, CATEGORY_OUTPUT) and typed as boolean, path, flag, or arrays. Representative options include:

• --editorconfig — "Take editorconfig into account when parsing configuration" Source: [src/cli/cli-options.evaluate.js:1-10]().
• --error-on-unmatched-pattern — "Prevent errors when pattern is unmatched" Source: [src/cli/cli-options.evaluate.js:11-13]().
• --file-info — emits a JSON object with ignored and inferredParser for a given path Source: [src/cli/cli-options.evaluate.js:14-23]().
• --find-config-path — "Find and print the path to a configuration file for the given input file" (CATEGORY_CONFIG) Source: [src/cli/cli-options.evaluate.js:24-30]().
• --help / -h — usage info, supports --help <flag> to inspect a specific option Source: [src/cli/cli-options.evaluate.js:31-39]().
• --ignore-path — defaults to [".gitignore", ".prettierignore"] and accepts multiple values Source: [src/cli/cli-options.evaluate.js:40-50]().
• --ignore-unknown / -u and --list-different / -l — for filtering and CI reporting Source: [src/cli/cli-options.evaluate.js:51-58]().

The schema is evaluated lazily (the filename itself ends in .evaluate.js) so each invocation only pays the cost of the options it needs.

Output, ignore, and editorconfig

The default ignore list is intentionally minimal (.gitignore plus .prettierignore), and --ignore-path is array-typed, so users can layer additional ignore files in CI or monorepos. The --list-different flag is the canonical CI switch — it prints only the names of files that would change, which is how pipelines gate "did the formatter run?" checks.

Programmatic API

While the CLI lives in bin/prettier.cjs, the programmatic surface is exposed through the package's exports map. The same formatting engine is reachable as:

• import prettier from "prettier" (ESM) or require("prettier") (CJS) — the unified API used by tooling authors.
• import "prettier/standalone" — the browser/UMD bundle that ships in the published dist/ and is also referenced via the unpkg and browser fields Source: [package.json:9-21]().
• import pluginX from "prettier/plugins/<lang>" — language-specific printer modules resolved by the ./plugins/* export pattern.

The website is built on Docusaurus and consumes the same Prettier build; yarn build:website builds the browser bundles that power the Playground, and the docs from docs/ are copied into website/versioned_docs/version-stable at release time so that https://prettier.io/docs/ always tracks the latest stable version Source: [website/README.md:5-45]().

Plugin & Editor Ecosystem

Plugin package layout

@prettier/plugin-hermes is a representative first-party plugin. It uses a self-contained package layout — package.json declares type: "module", scoped exports (with both types and default entries), a sideEffects: false hint for tree-shaking, and a directory field pointing back at the monorepo Source: [packages/plugin-hermes/package.json:1-23]().

Consumers enable it by adding it to the plugins array of a Prettier config:

// prettier.config.mjs
import * as prettierPluginHermes from "@prettier/plugin-hermes";

/** @type {import("prettier").Config} */
const config = {
  plugins: [prettierPluginHermes],
};

export default config;

The README also documents a lower-level integration via the overrides array, which lets users pin a custom parser to a glob of files. The plugin is declared as requiring prettier>=3.6.0 Source: [packages/plugin-hermes/README.md:1-49]().

Editor support

The home page renders an EditorSupportSection that walks the curated list of editor integrations (siteConfig.customFields.editors) and renders each as a card with logo, name, and Markdown body. Each card links back to the source of truth at website/data/editors.yml, and the section explicitly invites the community to add new integrations via PR Source: [website/src/pages/index.jsx:1-35]().

Adoption signals

The /users page is itself part of the integration story: it surfaces adoption metrics from the State of JS surveys (e.g. "More than 83% of respondents to State of JS 2021") and showcases a logo grid of projects that depend on Prettier, with a link back to npm's reverse-dependency view for the full list Source: [website/src/pages/users/index.jsx:1-30]().

Integration architecture

flowchart LR
    A[Shell / CI] -->|--prettier.cjs| B[CLI entry]
    C[Node tool / Editor host] -->|import 'prettier'| D[Programmatic API]
    E[Browser bundle] -->|prettier/standalone| D
    B --> F[Core formatter]
    D --> F
    F --> G[Parser plugins]
    F --> H[Printer plugins]
    G -.-> I[prettier/plugins/*]
    H -.-> J[3rd-party plugins]

Every entry point funnels into the same formatter core, and the plugin packages registered through exports["./plugins/*"] or user plugins arrays are the extension points that the CLI, API, and browser bundle all share.

See Also

• Prettier Options Reference
• Editor Integrations List
• Plugin Authoring Guide
• Pre-commit & CI Setup

Doramagic Pitfall Log

Found 25 structured pitfall item(s), including 1 high/blocking item(s). Top priority: Maintenance risk - Maintenance risk requires verification.

1. Maintenance risk: Maintenance risk requires verification

• Severity: high
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/prettier/prettier/issues/19339

2. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Dependency Dashboard
• User impact: Developers may fail before the first successful local run: Dependency Dashboard
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Dependency Dashboard. Context: Observed when using node
• Evidence: failure_mode_cluster:github_issue | https://github.com/prettier/prettier/issues/15461

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/prettier/prettier/issues/15461

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/prettier/prettier/issues/19332

5. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Disable New line at then end of file
• User impact: Developers may misconfigure credentials, environment, or host setup: Disable New line at then end of file
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Disable New line at then end of file. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/prettier/prettier/issues/6360

6. Capability evidence risk: Capability evidence risk requires verification

• Severity: medium
• Finding: README/documentation is current enough for a first validation pass.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: capability.assumptions | github_repo:75104123 | https://github.com/prettier/prettier

7. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Developers should check this migration risk before relying on the project: 3.8.4
• User impact: Upgrade or migration may change expected behavior: 3.8.4
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: 3.8.4. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/prettier/prettier/releases/tag/3.8.4

8. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Developers should check this migration risk before relying on the project: Release v3.9
• User impact: Developers may hit a documented source-backed failure mode: Release v3.9
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Release v3.9. Context: Observed when using node
• Evidence: failure_mode_cluster:github_issue | https://github.com/prettier/prettier/issues/19332

9. Maintenance risk: Maintenance risk requires verification

• Severity: medium
• Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: evidence.maintainer_signals | github_repo:75104123 | https://github.com/prettier/prettier

10. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: downstream_validation.risk_items | github_repo:75104123 | https://github.com/prettier/prettier

11. Security or permission risk: Security or permission risk requires verification

• Severity: medium
• Finding: no_demo
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: risks.scoring_risks | github_repo:75104123 | https://github.com/prettier/prettier

12. Capability evidence risk: Capability evidence risk requires verification

• Severity: low
• Finding: Developers should check this capability risk before relying on the project: Markdown: Formatting ordered list containing a number greater or equal to 999999999999999934464 converts the number into decimal exponential notation
• User impact: Developers may hit a documented source-backed failure mode: Markdown: Formatting ordered list containing a number greater or equal to 999999999999999934464 converts the number into decimal exponential notation
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Markdown: Formatting ordered list containing a number greater or equal to 999999999999999934464 converts the number into decimal exponential notation. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/prettier/prettier/issues/17778

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using prettier with real data or production workflows.

• Dependency Dashboard - github / github_issue
• Paragraph can be turned into heading with --prose-wrap preserve - github / github_issue
• Release v3.9 - github / github_issue
• Disable New line at then end of file - github / github_issue
• Should not increase ordered list mark - github / github_issue
• Markdown: Formatting ordered list containing a number greater or equal t - github / github_issue
• 3.8.4 - github / github_release
• 3.8.3 - github / github_release
• 3.8.2 - github / github_release
• 3.8.1 - github / github_release
• 3.8.0 - github / github_release
• 3.7.4 - github / github_release