Plugin packages declare empty version ranges for `@perspective-dev/client` / `@perspective-dev/viewer`, allowing mixed-version installs

[timkpaine]

Affected versions

• @perspective-dev/viewer-datagrid 5.2.0 and 5.3.0 (verified in both published tarballs).
• @perspective-dev/viewer-charts 5.2.0 and 5.3.0 have the related-but-worse variant: no dependencies field at all.

What happens

@perspective-dev/viewer-datagrid's published package.json (5.3.0):

"dependencies": {
    "@perspective-dev/client": "",
    "@perspective-dev/viewer": "",
    "regular-table": "=0.9.0"
}

The empty string is a valid semver range that matches any version (equivalent to *). So the plugin never constrains which client/viewer it runs against. @perspective-dev/viewer-charts goes further — its published package.json declares no dependencies at all, while its ESM bundle (dist/esm/perspective-viewer-charts.js) imports @perspective-dev/viewer; it works only via hoisting.

Consequence: when a consumer bumps the top-level packages 5.2.0 → 5.3.0, a stale pnpm lockfile legitimately keeps the old viewer resolved for the plugin subtree — the empty range is satisfied by 5.2.0, so pnpm has no reason to re-resolve it. Result: two viewer copies in one node_modules.

Reproduction

1. Install @perspective-dev/viewer@5.2.0 + @perspective-dev/viewer-datagrid@5.2.0 with pnpm; commit the lockfile.
2. Bump only the top-level specifiers to 5.3.0 and pnpm install (no pnpm update/dedupe).
3. node_modules/.pnpm now contains both @perspective-dev+viewer@5.2.0... and @perspective-dev+viewer@5.3.0...; the datagrid subtree still links 5.2.0 because "" is satisfied.

[LarryHu0217]

I reproduced this on current master (8e1e284) with the repository's CI pnpm major (pnpm 9.15.9): packing workspace: produces empty dependency ranges, while workspace:^ produces ^5.3.0.

I have a focused patch ready that:

• changes the datagrid plugin's client and viewer runtime dependencies to workspace:^;
• moves the charts plugin's actual client and viewer imports from devDependencies to dependencies, also using workspace:^;
• verifies the two generated .tgz manifests in the publish job, so future pnpm behavior changes cannot silently reintroduce this.

The verifier fails against the published 5.3.0 archives and passes against both patched pnpm 9 archives. Lockfile consistency, Prettier, and Node syntax checks pass. Since the contribution guide requires a maintainer-tagged issue before a PR, would you like me to submit this patch? For this manifest/release-workflow-only change, is the targeted package validation sufficient, or do you require the full monorepo build and test suite locally as well?