Console errors for md files with invalid typescript blocks gives no feedback for which block failed

[rebasecase]

Minimal example:

test.md

```typescript
-
```

prettier ./test.md

README.md [error] [prettier-plugin-sort-imports]: import sorting aborted due to babel parsing error.
```typescript
-
```

I'm not sure what to do in this instance? Is it possible to get debug info here to say where/which code block it thinks I messed up?

[IanVS]

Can you please update to v4.5.0 and try again? And also share your prettier config? I'm not able to reproduce the issue so far.

[rebasecase]

{
  "useTabs": false,
  "tabWidth": 2,
  "singleQuote": true,
  "trailingComma": "none",
  "printWidth": 100,
  "plugins": [
    "prettier-plugin-svelte",
    "prettier-plugin-tailwindcss",
    "@ianvs/prettier-plugin-sort-imports"
  ],
  "overrides": [
    {
      "files": "*.svelte",
      "options": {
        "parser": "svelte"
      }
    }
  ]
}

This was 4.4.2, I shall try 4.5 in a bit thanks

[rebasecase]

"prettier": "^3.6.2",
"prettier-plugin-svelte": "^3.4.0",
"prettier-plugin-tailwindcss": "^0.6.14",
"@ianvs/prettier-plugin-sort-imports": "^4.5.1",

Thanks! This is better, it gives feedback, but it doesn't give me a hint at which block!

README.md

This is a test readme

```typescript
const a = 1;
```

```typescript
-
```

pnpm prettier ./README.md

README.md [error] [prettier-plugin-sort-imports]: import sorting aborted due to parsing error:
SyntaxError: Unexpected token (1:1)
    at constructor (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:367:19)
    at TypeScriptParserMixin.raise (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:6627:19)
    at TypeScriptParserMixin.unexpected (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:6647:16)
    at TypeScriptParserMixin.parseExprAtom (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:11442:16)
    at TypeScriptParserMixin.parseExprSubscripts (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:11076:23)
    at TypeScriptParserMixin.parseUpdate (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:11061:21)
    at TypeScriptParserMixin.parseMaybeUnary (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:11041:23)
    at TypeScriptParserMixin.parseMaybeUnary (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:9852:18)
    at TypeScriptParserMixin.parseMaybeUnary (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:11024:28)
    at TypeScriptParserMixin.parseMaybeUnary (/workspaces/project/node_modules/.pnpm/@babel+parser@7.28.0/node_modules/@babel/parser/lib/index.js:9852:18) {
  code: 'BABEL_PARSER_SYNTAX_ERROR',
  reasonCode: 'UnexpectedToken',
  loc: [Position],
  pos: 1,
  syntaxPlugin: undefined
}
This is a test readme

```typescript
const a = 1;
```

```typescript
-
```

.prettierrc

{
  "useTabs": false,
  "tabWidth": 2,
  "singleQuote": true,
  "trailingComma": "none",
  "printWidth": 100,
  "plugins": [
    "prettier-plugin-svelte",
    "prettier-plugin-tailwindcss",
    "@ianvs/prettier-plugin-sort-imports"
  ],
  "overrides": [
    {
      "files": "*.svelte",
      "options": {
        "parser": "svelte"
      }
    }
  ]
}

[rebasecase]

N.B. removing "@ianvs/prettier-plugin-sort-imports" from plugins it does not have problem parsing it (or rather, silently fails and ignores the blocks it can not parse) e.g. without the sort imports plugin and running pnpm prettier ./README.md --write for

```typescript
    const a = 1;
```

```typescript
-
    const b = 2;
```

it becomes

```typescript
const a = 1;
```

```typescript
-
    const b = 2;
```

[fbartho]

@rebasecase Silently failing seems generally bad, but maybe that’s okay in the specific case of MDX

This sounds like a Feature request to allow silent formatting failures for MDX specifically?
I don’t love that idea personally but maybe that’s the right choice.

[fbartho]

Otherwise this is a Feature Request for the MDX formatter — I feel like they’re the ones who can & should report errors on formatting specific blocks?

[rebasecase]

Silently failing seems generally bad

I agree. It would be good to warn at least that it failed a particular block, and have some special language tag to say that it is meant to fail in cases where this is desired behaviour --- I have no idea if this is already a feature.

I'm not deeply familiar with the inner workings of Prettier or which modules handle specific tasks, so I’m unsure exactly what to request or where the best place to report this would be. Sorry if this isn’t the appropriate repository.

Could you explain why adding the import sorting triggers the error to appear? It still appears to be run on the .md file code blocks, since, for instance, it formats the spacing correctly.

(this is a regular markdown file, not mdx if that makes a difference)

[fbartho]

I'm not deeply familiar with the inner workings of Prettier or which modules handle specific tasks, so I’m unsure exactly what to request or where the best place to report this would be. Sorry if this isn’t the appropriate repository.

No apology required! This is how you learn!
As a direct answer: the MDX plugin is the one that is calling into prettier again with the context of specific blocks instead of the whole file. The more I think about it, the more I think they’re intentionally suppressing error messages, because invalid code-snippets is probably a common case for them or for documentation in general. — If they pass some sort of configuration flag to all the plugins so we can detect we’re supposed to suppress error logs, then we can add a feature to respect that.

Could you explain why adding the import sorting triggers the error to appear? It still appears to be run on the .md file code blocks, since, for instance, it formats the spacing correctly.

I specifically chose to log errors explicitly because I felt like silent errors were bad and as I got involved in this plugin I found tons of situations where prettier was inconsistent in reporting errors:

prettier-plugin-sort-imports/src/preprocessors/preprocessor.ts

Lines 33 to 39 in 040fa5e

	} catch (err) {
	console.error(
	' [error] [prettier-plugin-sort-imports]: import sorting aborted due to parsing error:\n%s',
	err,
	);
	return code;
	}

[IanVS]

We are using babel to parse the code prettier sends us into an AST in order to identify import statements and organize them. If babel finds invalid syntax, it throws an error (that is its default behavior).

HOWEVER, it does have an option, errorRecovery, which will try to be more tolerant of errors. In fact, prettier sets that option itself, which is probably why it's able to format code even when there is invalid syntax: https://github.com/prettier/prettier/blob/65ad428bcadc68f6975f0f595236fb3455ff7ab8/src/language-js/parse/babel.js#L24C7-L34

These are the docs from babel:

errorRecovery: By default, Babel always throws an error when it finds some invalid code. When this option is set to true, it will store the parsing error and try to continue parsing the invalid input file. The resulting AST will have an errors property representing an array of all the parsing errors. Note that even when this option is enabled, @babel/parser could throw for unrecoverable errors.

So, theoretically we could (and maybe should) mirror the parser options that prettier itself uses. I need to think about that a little bit more, and experiment with it to see if that works how we might want. We might even consider applying the default babel parser plugins that prettier uses...

[rebasecase]

@fbartho

If they pass some sort of configuration flag to all the plugins so we can detect we’re supposed to suppress error logs, then we can add a feature to respect that.

That seems like a great idea.

@IanVS

In theory, we could (and perhaps should) align with the parser options that Prettier itself uses.

For now, that might work. But I think what's missing is an option to emit a warning or error for an unparseable code block - and to emit where in the file this block is - with ability that plugins could detect the way @fbartho described. I think this would be prettier’s responsibility to implement this for hthe mdx parsing?