pnpm-workspace-utils

I followed the instructions, but get an error. Below is a minimal reproduction. Test: Notes: If I remove the json config block, then it works If I use in the json config block, then it works; but that means the file will not be linted by other rules and plugins Is this plugin compatible with a config that also lints json?* (PS: above details the JSON problem - maybe the same exists for YAML.)

Clear and concise description of the problem At this time this plugin uses the older language parsers and not the modern language features from eslint. https://eslint.org/docs/latest/use/configure/plugins#specify-a-language This can cause some comparability issues when trying to use with plugins that are executing on the same files. Suggested solution This plugin could use the yaml and json language features from https://github.com/ota-meshi/eslint-plugin-yml#languages and https://github.com/eslint/json Example from another plugin making the json migration to language features. https://github.com/michaelfaith/eslint-plugin-package-json/blob/main/docs/plans/parser-to-language-migration/plan.md Alternative Continuing to only support the legacy parser pattern Additional context _No response_ Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

What Adds an opt-in YAML rule that reports pnpm's anonymous top-level key in , for workspaces that standardise on named catalogs. is deliberately not reported — it is already the named form, even though pnpm resolves bare specifiers to it. Notes Not fixable. Rewriting into would silently break every bare specifier across the workspace's files, which a YAML-scoped rule can't rewrite reliably. Report-only seemed the honest option. Not enabled in — preferring named catalogs is a style choice, not a correctness one, so it follows in being registered but opt-in. Follows the existing YAML rule shape (filename guard → → / bail → ), and reports on the key node so the error lands on rather than the whole block. Known interaction worth flagging defaults , and writes when is absent (). So with both rules on, can generate the very this rule then reports, with no autofix to undo it. Setting to a named catalog avoids it, so it is not a blocker — but it's arguably a sign the preference belongs on the write side too. Happy to follow up separately if you think that's worth changing. Testing 6 new cases in (named catalogs, , no catalogs; anonymous alone, alongside named, and empty). Full suite green at 87/87, clean, and the rule passes against this repo's own . 🤖 Generated with Claude Code