Environments:

• Prettier Version: 3.0.0-alpha.3
• Running Prettier via: Node.js API
• Runtime: Node 16, 18
• Operating System: macOS
• Prettier plugins (if any): @ianvs/prettier-plugin-sort-imports

Steps to reproduce:

I maintain a fork of a popular prettier plugin (https://github.com/trivago/prettier-plugin-sort-imports is the original), and we both have this issue, as does https://github.com/tailwindlabs/prettier-plugin-tailwindcss and any other plugin which adds a preprocess to built-in parsers. They all break in prettier 3.0.

I traced it down to a change in the way that parsers are chosen in resolveParser. Previously, the "last" plugin in the loop which defined a parser for a given name would win. Since custom plugins come at the end of the plugin array, this meant they were able to override built-in parsers. But now, by using a for .. of loop with an early exit, the first plugin defining a parser will be used, giving plugins no chance to override or extend them.

Expected behavior:

Plugins should continue to have a way to extend built-in parsers. Or, if we need to define our own custom parsers, we need a way to determine which parser would have been chosen by prettier, so that users do not need to explicitly map their file types to our custom parsers. But again, ideally the previous behavior would be maintained.

Actual behavior:

Custom plugins cannot extend built-in parsers.