fix: prevent call stack overflow when used with prettier-plugin-tailwindcss

[shun-shobon]

fix #254

The root cause was that prettier-plugin-jsdoc delegates parse/preprocess to “another plugin that provides the same parser” by scanning options.plugins, but it could accidentally pick a plugin that appears after prettier-plugin-jsdoc (e.g. tailwindcss). Since tailwindcss wraps other parsers, delegating back to it from inside jsdoc creates a circular call chain like tailwind.preprocess -> jsdoc.preprocess -> tailwind.preprocess -> ..., eventually overflowing the call stack.

To prevent this, findPluginByParser() now only considers plugins that appear before prettier-plugin-jsdoc in options.plugins, avoiding delegation back into wrapper plugins while preserving compatibility with earlier parser plugins.

[danielpza]

LGTM, please update the README adding a note about this behavior.
Can you also add some tests.

[RobertOstermann]

@shun-shobon @danielpza Any update on when this will be merged/released?

[iainlane]

Thanks for working on this. I looked at this while I was working on #254, and I think this PR is pointing at the right problem: prettier-plugin-jsdoc can end up delegating back into a plugin that wraps/re-resolves the parser chain, which creates recursive preprocess/parse calls.

I think the ordering-based fix here is a bit narrower than we want, though. It avoids one Tailwind path by only looking at plugins before prettier-plugin-jsdoc, but parser re-entry can still happen when a chaining plugin appears before jsdoc, and it does not cover parse-time re-entry.

I tested this branch by copying over my tests from #254, and it still overflows when the chaining plugin is first. The fix over there handles this at the parser boundary instead: cache the merged parser, track active preprocess/parse calls per Prettier options object, and fall back to the raw parser only for recursive entries in the same format call. That covers both plugin orders and concurrent format calls.

So I think this PR identified the right area, but I’d prefer the guard-based approach with regression tests over the plugin-order heuristic. Thanks again for digging into it.