@terrazzo/parser declares fast-deep-equal but never imports it

[HeversonSilva-gif]

Versions

• @terrazzo/parser: 2.5.0
• @terrazzo/cli: 2.5.0

Node.js version

22.14.0

OS + version

Windows 11 (10.0.26200)

Description

@terrazzo/parser declares fast-deep-equal in dependencies, but nothing in the package
imports it. It is installed by everyone who installs the parser, and by extension everyone
who installs @terrazzo/cli, without ever being loaded.

This is a packaging issue rather than a runtime one — nothing misbehaves, there is just a
package in the tree that no code path reaches.

The one place that would plausibly use it still does not. In
packages/parser/src/lint/plugin-core/rules/duplicate-values.ts the comment reads
// everything else: use deepEqual, and the code below it compares with
JSON.stringify(t.$value) === JSON.stringify(v), carrying its own
// TODO: don't JSON.stringify. So the intent was there, but fast-deep-equal was never
wired up.

I found this with a scanner that looks for declared dependencies absent from the published
files, then verified this one by hand.

Reproduction

At 8753761:

1. git grep -E "(from|require\(|import\()\s*['\"]fast-deep-equal" returns nothing.
   git grep fast-deep-equal matches only packages/parser/package.json and
   pnpm-lock.yaml.
2. Remove the fast-deep-equal line from packages/parser/package.json, then
   pnpm install.
3. pnpm run build — 19 tasks successful, exit 0, same as before the change.
4. pnpm --filter @terrazzo/parser run test — 25 test files passed, 266 passed,
   1 skipped. Byte-identical counts to the baseline I captured before removing it.

Baseline for comparison, captured on the unmodified checkout: build exit 0, and the same
25 / 266 / 1.

One note on running this: pnpm --filter @terrazzo/parser run test fails with 24 of 25
files erroring if the workspace has not been built first. pnpm run build at the root
fixes it. That is not related to this issue, but it cost me a confusing first run.

Expected result

fast-deep-equal is not installed, since no code imports it. Either it is removed from
dependencies, or duplicate-values.ts starts using it in place of the JSON.stringify
comparison the TODO already flags.

I have no opinion on which of those you prefer, and the second is a behaviour change I
would not want to make uninvited — JSON.stringify is order-sensitive where a real deep
equal is not, so switching could change which tokens the rule reports as duplicates.

Extra

• I'm willing to open a PR (see CONTRIBUTING.md)

The removal is ready to go and verified as above. I have not opened it, since CONTRIBUTING
asks for an issue first.

[drwpow]

Ah yeah this can be removed. It was using it in the past, but was a perf bottleneck so it was replaced.