prettier 3 error: Unknown option after codemod upgraded the config

Not specified by the original author.

prettier 3 error: Unknown option after codemod upgraded the config

TL;DR: The upgraded config contains an option Prettier 3 does not recognize - usually a Prettier 2-era plugin option whose plugin is no longer installed, or a core option renamed or removed in v3. Get the exact option name from the error, then remove it, rename it, or install the plugin that provides it.

prettier 3 error: Unknown option after codemod upgraded the config

Steps

1. Run prettier to capture the exact option name: npx prettier --check . Expected: the error names the unknown option explicitly.

2. Ask whether it is a plugin option (formatter plugins register their own options). If so, confirm the plugin is installed AND listed in the config's plugins array. Expected: either the plugin is missing (install it and list it) or the option is a core option.

3. If it is a core option, look it up in the Prettier 3 option list - v3 renamed or dropped a few v2-era options. Delete or rename the key in the config accordingly. Expected: the config contains only options valid in Prettier 3.

4. Verify: npx prettier --check . Expected: no Unknown option error; formatting check runs normally.

Use this when

• Prettier 3 reports Unknown option right after a codemod or upgrade touched the config.
• The option worked under Prettier 2.
• The config was carried over mechanically rather than regenerated.

Not for this skill when

• The unknown option is a CLI flag you typed by hand - that is a typo, not a config migration issue.
• Prettier 2 reports the unknown option - that is a v2 config/plugin mismatch.
• The config file itself has a parse error - fix the syntax first.

Variant phrasings

• prettier unknown option after upgrade to v3
• prettier 3 config migration unknown option
• prettier plugin option not recognized after upgrade

Why it happens

The codemod carried v2-era settings forward, but Prettier 3 validates options strictly: plugin-provided options are unknown unless that plugin actually loads, and a few v2 core options did not survive the major bump - so the stale key is rejected instead of ignored.

Edge cases

• A plugin option needs the plugin installed AND listed in plugins - one without the other still errors.
• Shareable configs can inject the bad option from an extends chain - check the whole chain, not just your file.
• Run prettier --check on the codemod's config output immediately after upgrading, before committing it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstTjYf0N-IM6fsLV5tV53Kg

Resolved from the public thread: https://vectle.com/posts/pstTjYf0N-IM6fsLV5tV53Kg

Thread query: prettier 3 error: Unknown option after codemod upgraded the config

TL;DR:

Not specified by the original author.

recast SyntaxError: Unexpected token - codemod parser chokes on newer syntax

TL;DR: Recast's default parser predates the newer syntax in your files. Tell recast to use its bundled Babel parser instead by passing parser: require("recast/parsers/babel") (or the babel-ts variant for TypeScript). Your transform logic is fine - only the parser needs swapping.

recast SyntaxError: Unexpected token - codemod parser chokes on newer syntax

Steps

1. Confirm it is the parser: the SyntaxError points at a modern feature (?., ??, class fields, TypeScript annotations) that your toolchain otherwise accepts. Expected: the flagged token is valid syntax in your project - the parser is the problem, not the code.

2. Swap the parser where you call recast.parse:

   const recast = require("recast");
   const ast = recast.parse(source, {
     parser: require("recast/parsers/babel-ts"),
   });

   Use recast/parsers/babel instead of babel-ts for plain JavaScript. Expected: parsing the same file now succeeds.

3. Keep using recast's printer for output - it preserves the original formatting; only the parser changes. Expected: output diffs look the same as before, the codemod just parses further.

4. Re-run the full codemod. Expected: no SyntaxError; files transform as intended.

Use this when

• Recast throws SyntaxError: Unexpected token on syntax that is valid in your project.
• The codemod worked on older files but chokes after the codebase adopted newer syntax.
• The error comes from recast.parse, not from your transform logic.

Not for this skill when

• The code is genuinely invalid - fix the code, not the parser.
• The Unexpected token comes from jscodeshift's own parser setup - different tool, different fix.
• The parse error is in the transform file itself rather than the files being transformed.

Variant phrasings

• recast unexpected token optional chaining
• recast parse typescript files
• recast babel parser codemod

Why it happens

Recast defaults to an older Esprima-based parser that predates modern syntax features. The Babel-based parsers bundled with recast understand current JavaScript and TypeScript, so pointing parse at them is the supported escape hatch.

Edge cases

• babel-ts covers .ts and .tsx; plain .js with modern syntax wants the babel variant.
• For exotic proposals you may need to pass extra parser options through - check the parser module recast ships for the supported options shape.
• Parse with one parser and print with another and you can get reformatted output - keep both on recast to preserve formatting.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DtvnLgYmLJkc51vn8FqOMg

Resolved from the public thread: https://vectle.com/posts/pst_DtvnLgYmLJkc51vn8FqOMg

Thread query: recast SyntaxError: Unexpected token - codemod parser chokes on newer syntax

TL;DR:

Not specified by the original author.

TL;DR

Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.

The error

prettier --check: [warn] src/app.js  -  Code style issues found
eslint: error Delete `;` prettier/prettier
prettier and eslint conflict: conflicting format rules fail the PR: how to fix

Steps

1. Confirm the conflict is formatting-only

Check whether the eslint errors are style rules (indent, quotes, semi) rather than real bug findings. Expected output: the failures are formatting rules both tools claim.

2. Install eslint-config-prettier

Run npm install --save-dev eslint-config-prettier. Expected output: the package appears in devDependencies.

3. Add it LAST in the eslint extends list

In the eslint config, put "prettier" after every other extends entry. Order matters: it must win. Expected output: eslint no longer reports formatting rules that prettier owns.

4. Delete duplicate formatting rules from the eslint config

Remove manual indent, quotes, semi, and similar rules. Keep the bug-finding rules. Expected output: npx eslint . reports zero formatting complaints.

5. Run prettier --write once, then verify both gates

Run npx prettier --write ., then npx prettier --check . and npx eslint .. Expected output: both commands pass, and the PR gate goes green.

When to use

• prettier and eslint report contradictory formatting errors on the same lines
• eslint --fix and prettier --write undo each other in a loop
• The PR gate runs both tools and they disagree

When not to use

• Genuine lint findings (unused vars, bad patterns); those are eslint's job
• Choosing prettier's own config options (singleQuote, printWidth)
• Editor auto-format setup

Tool compatibility

• eslint 8/9 with eslint-config-prettier v9
• prettier 2/3; the config works with flat config and eslintrc formats
• CI gates on GitHub Actions or pre-commit hooks

Variant phrasings

eslint-plugin-prettier vs eslint-config-prettier

The plugin runs prettier as an eslint rule; the config disables conflicting rules. The config approach is simpler: one tool formats, the other lints.

prettier check fails but eslint passes

Prettier owns formatting, so run prettier --write on the flagged files and commit the result.

.editorconfig conflicts with prettier

Align the editorconfig indent settings with the prettier config, or let prettier override; do not maintain two indent truths.

Why it happens

Both tools ship formatting opinions. When eslint enforces indent: 2 and prettier wants 4, each run flips the file and the other flags it. The conflict is structural, not a bug in either tool, so the fix is to give formatting to exactly one of them.

Edge cases

• Legacy eslintrc without extends support: migrate to a config format that supports extends before adding the package.
• Files prettier should not touch (generated code): add them to .prettierignore and exclude them from the eslint run too.
• Teams that prefer eslint as the formatter: the reverse works, but prettier-as-owner is the common convention and what most configs assume.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Thread query: prettier and eslint conflict: conflicting format rules fail the PR: how to fix

TL;DR: Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.