fix(integrity): dedupe resolved packageIds at the source (#506) (#509)

Fixes #506. Alternative to #507.

## What changes for users

`mops install` (and any flow that runs `--lock check`) no longer fails
with `Mismatched number of resolved packages: N vs M` on projects whose
resolved deps include multiple aliases (e.g. `base`, `base@0`,
`base@0.16`) pinned to the same `name@version`. Previously the only
workaround was `--lock ignore`.

## Root cause

`getResolvedMopsPackageIds` returned a list with duplicates:
`resolvePackages()` keeps each alias as its own entry, then
`getPackageId` collapses the alias suffix via `getDepName`, so two
aliases pinning the same `name@version` produced the same id twice.
`mops.lock`'s `hashes` is keyed by packageId and naturally dedup'd, so
the count comparison in `checkLockFile` mismatched.

## Why this approach over #507

#507 dedupes only at the count comparison. This PR dedupes inside
`getResolvedMopsPackageIds`, which (a) makes the function's contract
match its name, and (b) stops sending duplicate ids to the canister's
`getFileHashesByPackageIds`. Downstream membership checks (`includes`,
`in`) were already dedupe-safe, so no other call site needed changes.

## Test plan

Added a regression fixture pinning `core` and `core@1` to `1.0.0` plus a
test asserting `mops install` exits clean and stderr doesn't contain the
mismatch error. Verified that reverting the fix makes the Jest test fail
with the expected error string.

Author: Kamirus

cli/CHANGELOG.md

@@ -1,6 +1,7 @@
 # Mops CLI Changelog
 
 ## Next
+- Fix `mops install` (and any `--lock check` flow) failing with "Mismatched number of resolved packages" when a project's resolved dependencies include multiple aliases (e.g. `base`, `base@0`, `base@0.16`) that pin to the same `name@version`
 
 ## 2.12.1
 - `mops check`/`build`/`check-stable` skip migration staging when only the pending `next` migration is needed, so `moc` diagnostics reference the real `next-migration/<file>` path.

cli/integrity.ts

@@ -63,7 +63,8 @@ async function getResolvedMopsPackageIds(): Promise<string[]> {
   let packageIds = Object.entries(resolvedPackages)
     .filter(([_, version]) => getDependencyType(version) === "mops")
     .map(([name, version]) => getPackageId(name, version));
-  return packageIds;
+  // dedupe: aliases like `base@0`, `base@0.16` collapse to the same packageId
+  return [...new Set(packageIds)];
 }
 
 // get hash of local file from '.mops' dir by fileId

cli/tests/cli.test.ts

@@ -71,4 +71,25 @@ describe("install", () => {
 
   // mops add/remove/update/sync are not separately tested here because they
   // all route through the same checkIntegrity code path tested above.
+
+  // Regression: aliases pinning the same package@version (e.g. `core` and
+  // `core@1` both at "1.0.0") inflated the resolved-packageIds count and
+  // tripped the lockfile integrity check with a spurious
+  // "Mismatched number of resolved packages" error. See issue #506.
+  test("integrity check passes when aliases resolve to the same package@version", async () => {
+    const cwd = path.join(import.meta.dirname, "install/aliases");
+    const lockFile = path.join(cwd, "mops.lock");
+    rmSync(lockFile, { force: true });
+    try {
+      const result = await cli(["install"], { cwd, env: { CI: undefined } });
+      expect(result.stderr).not.toMatch(
+        /Mismatched number of resolved packages/,
+      );
+      expect(result.exitCode).toBe(0);
+      expect(existsSync(lockFile)).toBe(true);
+    } finally {
+      rmSync(lockFile, { force: true });
+      rmSync(path.join(cwd, ".mops"), { recursive: true, force: true });
+    }
+  });
 });

cli/tests/install/aliases/mops.toml

@@ -0,0 +1,3 @@
+[dependencies]
+core = "1.0.0"
+"core@1" = "1.0.0"