vscode-pnpm-catalog-lens

Description Adds a hover provider that shows package description, latest version (with relative publish time), and homepage when you hover a catalog entry. Works across all three supported workspace formats: pnpm: yarn: bun: root (root-level / plus the legacy / shape) Uses pacote to fetch package metadata. Handles , scoped packages, auth tokens, and registry resolution natively. Thanks to @ikeyan for the suggestion. Linked Issues resolves #4 Additional context 1. Respects (same gate VS Code's built-in npm extension uses for hovers.) Off → no hover. 2. helper for relative date formatting is adapted from VS Code's npm extension date.ts Demo: https://github.com/user-attachments/assets/4b605690-111f-44fa-a3f5-e21517bd5354

Describe the bug When opening a inside a Bun workspace, the extension logs: I tracked this down to , and disabling the extension makes the message go away. In my case the workspace is using Bun, but there is no / yet. VS Code is also configured with . I think this case should not be treated as an error. If no is present, maybe the extension can fall back to other Bun signals, for example: in the root Bun workspace/catalog fields in the root At minimum, this log probably should not be . Reproduction 1. Create a Bun workspace with catalogs in root 2. Do not generate / 3. Open a child package 4. Check the Debug Console System Info Used Package Manager bun Validations [x] Follow our Code of Conduct [x] Read the Contributing Guide. [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. [x] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead. [x] The provided reproduction is a minimal reproducible of the bug. Contributions [x] I am willing to submit a PR to fix this issue [ ] I am willing to submit a PR with failing tests (actually just go ahead and do it, thanks!)

Clear and concise description of the problem Rush stores the pnpm-workspace.yaml file (and other pkg managers' workspace files) in a custom location: common/temp. So it's not being picked up by this plugin. Suggested solution @antfu, would you accept a PR to add a new setting that would allow the script to look for the pnpm-workspace.yaml file in a custom location? It would be defaulted to monorepo root - so it wouldn't be a breaking change for anyone. Alternative _No response_ 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.