Discussion about integrating sem into diff-so-fancy

[scottchiefbaker]

I like the concept of sem so I took a run at seeing what it would take to integrate it into d-s-f. It ended up being pretty simple. Check out the sem_integration branch: https://github.com/so-fancy/diff-so-fancy/tree/sem_integration.

Definitely still needs some work, but I was pretty happy with it for 27 minutes of coding.

[rs545837]

Tested the branch, some improvements I think.

• on line 1373, I think it should be $? >> 8
• sem diff $file always diffs against HEAD, so piping git diff HEAD~3..HEAD shows the wrong sem info. Quick fix on your side would be checking for env vars like SEM_FROM/SEM_TO and passing them as --from/--to to sem. On our side we'll add a --patch mode that reads unified diff from stdin, so you can just pipe each file's diff chunk through instead of calling sem separately.
• Spawning sem diff per file is slow on big diffs. Could call it once without a file filter and parse the output.

Excited for the integration, do lemme know any feedback or if you hit any walls.

[nminev]

Adjacent to this integration discussion — I've been maintaining a fork at https://github.com/nminev/sem with a few changes that might be relevant to how this renders in d-s-f, since both come up in the diff summary:

1. Parent suppression for nested entities. When a method inside a class changes, only the leaf appears with a parent::child path (e.g. User::validate modified) instead of two separate entries (User modified + validate modified). For diff summary headers this halves the line count on the common case.

2. Recursive JSON entity extraction. Upstream's JSON parser is depth-2; ours recurses fully. So a package.json edit surfaces scripts::build rather than just scripts. This improves usefulness for config-heavy diffs (which I run into a lot).

3. Full ancestor chain in parent_name. A new field on each change carrying the joined chain (e.g. jest::config for an entry at /jest/config/testTimeout), so consumers can render full paths without traversing parent_id themselves.

Some of this is already proposed upstream — the parent_name field is in PR #97 and a precision fix to suppression is in PR #98 (both open). The JSON-specific changes aren't proposed yet because they depend on parent_name landing first and they involve a behavioral shift (the previous spec described double-reporting as intentional) that warrants a real design discussion.

Happy to bring these into the upstream repo if the maintainers agree with the direction. If the design view stays where it is, I'll keep maintaining the fork — it serves my own use case (diffing large JSON configs) regardless. Either way, flagging it here so this integration can pick whichever sem behavior fits best.

[nminev]

Quick update for anyone tracking this — all three improvements I mentioned are upstream now (#97, #98, #101 merged). The d-s-f integration can build on current sem directly, no fork needed.