Skip to content

feat(classifier): add rule for interface parent/extends removal (R32) #35

Description

@Aakif-Kohari

Summary

InterfaceSignature.extends?: string[] is extracted by all four language translators but is never consumed by any classification rule:

  • src/parsers/translators/typescript.tsextractExtends() (TS extends_type_clause / heritage_clause)
  • src/parsers/translators/java.tsextractExtendsInterfaces() (extends_interfaces)
  • src/parsers/translators/go.tsextractEmbeddedInterfaces() (embedded interfaces)
  • src/parsers/translators/rust.ts → trait bounds

src/core/types.ts even flags this directly on the field:

// removing a parent interface = breaking — callers relying on inherited properties break

Right now if a contributor removes interface Foo extends Baseinterface Foo,
Diff Guardian reports nothing, even though any caller relying on Base's members/type-compatibility through Foo silently loses that guarantee.

Proposed solution

Add R32: Interface Parent Removed — a new InterfaceRule that diffs oldSig.extends against newSig.extends and flags each parent present in the old signature but missing from the new one as breaking. Adding a new parent, or reordering existing ones, is not flagged (order-independent, addition-safe).

Since the field is already populated on all four translators, this is a classifier-only change — no parser/grammar work needed.

Scope

  • src/classifier/rules/R32_interface_extends_removed.ts (new rule)
  • src/classifier/rules/index.ts (export)
  • src/core/types.ts (add interface_extends_changed to ChangeType)
  • client/src/content/docs/rules-data.ts (docs entry)
  • tests/rules/interface-rules.test.ts (unit tests: positive, safe-addition,
    safe-reorder, identical, empty-array edge case)

Alternatives considered

Reusing interface_property_removed as the changeType — rejected, since the PR report/reporter should be able to distinguish "a field disappeared" from "a parent contract disappeared"; they have different remediation paths for the consumer.

Assignment

I'd like to work on this issue under ECSoC26. Will open a PR only after approval/assignment by @Aryan0628 or another maintainer.
And after R31 (#32 ) is merged, to avoid conflicting with it on the shared docs/index files.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions