Import statements can get messed up in TS

[kurtextrem]

Hi again, this one is a bit harder to reproduce exactly, because Weave seems to automatically do this:

Base:

import type { Foo } from "./foo"
import {
     type a,
     type b,
     type c,
} from "./foo"

Incoming change:

import {
     type Foo,
     type a,
     type b,
     type c,
} from "./foo"

What I've seen Weave produce a few times is this:
After:

     type Foo,
     type a,
     type b,
     type c,
} from "./foo"

(note the dropped import {)

[rs545837]

Thanks @kurtextrem for reporting this!

I wasn't able to reproduce the exact import { drop with the scenarios you described, but I found and fixed the underlying weakness: multi-line import blocks weren't being handled by the commutative import merge. When both sides added different specifiers to the same multi-line import, diffy would produce unnecessary conflicts (or potentially corrupt the output).

What changed:

• is_import_region now recognizes multi-line import blocks (continuation lines inside import { ... } are counted)
• merge_imports_commutatively handles multi-line imports as single units, merging specifiers as a set
• import_source_prefix extracts the source module from closing lines like } from "./foo"

Before: both sides adding different specifiers to the same import block = conflict.
After: clean merge, specifiers merged as a set.

Added 7 test cases covering consolidation, both-modify, adjacent-to-entity, and no-entity scenarios. If you can share a minimal repro that still triggers the dropped import {, I'd like to add that too.

[kurtextrem]

Thank you! I'll let you know if I can reproduce again.

[kurtextrem]

This is still happening for sure, e.g. on a rebase today:

} from "<file1>"
} from "<file2>"
} from "<file3>"
} from "<file4>"


} from "<file1>"
} from "<file2>"
} from "<file3>"
} from "<file4>"
<<<<<<< ours
} from "<file1>"
} from "<file2>"
} from "<file3>"
} from "<file4>"
||||||| original
} from "<file3>"
=======
>>>>>>> theirs
} from "<file3>"
} from "<file4>"

In my case it 1. introduced a conflict 2. made the file error (syntax error)

[rs545837]

Can you update and let me know if it's resolved on your end? with the last commit in place

[edouard-andrei]

Confirming we hit this too — weave 0.3.6 as the git merge driver, during stacked-branch rebases (force-rebasing a chain of branches, so the same imports get re-merged many times). TS import lines came out corrupted intermittently, including the partial-drop you describe (the import { opener lost, leaving an orphaned member list).

As you noted, the exact failure is hard to pin down because weave auto-consolidates imports. We did find one deterministic corner of that consolidation logic: when both sides add a different named member to the same existing import line, weave auto-resolves (exit 0, no conflict markers) but emits the import statement twice instead of merging the members:

// base.ts
import { a } from "mod";

function main() { return a; }

// ours.ts   -> import { a, b } from "mod";
// theirs.ts -> import { a, c } from "mod";

cp ours.ts out.ts
weave-driver base.ts out.ts theirs.ts -o out.ts -p sample.ts ; echo "exit=$?"

Actual (exit=0, no markers):

import { a, b } from "mod";
import { a, c } from "mod";

function main() { return a; }

Expected: a single merged import { a, b, c } from "mod";.

So the two observed failure modes — duplicated import statement (above, reliably reproducible) and dropped import { keyword (your report, intermittent) — look like the same import-consolidation/auto-resolve path going wrong.

This also appears to be the same root-cause family as #107 (a same-named function added at different positions on both sides is silently duplicated rather than unified): entities/imports get bound by position and treated as independent additions, instead of being unified by identity first. Filed #107 separately since it's a function-level, not import-level, manifestation.