* fix(vscode): fix cursor positioning when text ends with newline
A trailing newline is collapsed in a <div> with white-space: pre-wrap
but renders as a real empty line in the <textarea>. Without an extra
<br>, the overlay ends up one line shorter than the textarea, which
desyncs scrollTop and makes the visible caret appear one line off from
where the textarea actually inserts text.
* docs(vscode): simplify comment explaining trailing newline br element
Avoids the ls-remote + merge-base --is-ancestor walk in last() for the
common case by reading the recorded tag from .opencode-version. merge.ts
writes the file as part of the pre-merge compat commit so future runs of
fix-kilocode-markers, reset-to-upstream, and find-reset-candidates can
resolve the base tag instantly. Seeded with v1.14.33 (PR #9978).
git rerere learns conflict resolutions from past upstream merges and
replays them on the next merge. When past resolutions used the buggy
mergeWithNewestVersions ordering, rerere auto-resolves package.json
files with stale content before transformConflictedPackageJson ever
gets a chance to run — so the fixed merge logic never reaches the
file.
Add reconcileAllPackageJson, which runs after every merge (clean,
auto-resolved, or partially conflicted) and rewrites every package.json
that the merge touched from the kilo branch's pre-merge HEAD and the
opencode compat branch using the same merge logic. Files that are
still conflicted are skipped so manual resolution isn't silently
overwritten.
This makes our merge logic the source of truth for package.json
content, regardless of what rerere or git's textual merge produced.
Seeding the result with theirs' keys and appending ours-only keys at the
end caused kilo-only deps (e.g. rotating-file-stream in packages/core)
to relocate from the middle of the deps block to the end during the
pre-merge transform. Git's textual 3-way merge then saw ours keeping
the line in place and theirs adding the same key elsewhere, producing
a duplicate JSON key in the merged file.
Iterate ours first so kilo-only deps stay in their original position,
then append any theirs-only keys at the end.
The transform that materialises the 'kilo compat for vX.Y.Z' commit during
an upstream merge takes upstream's package.json wholesale and re-applies a
hand-picked list of Kilo scripts. That list was incomplete: it only covered
`extension`, `changeset`, `changeset:version`, `test`, and `test:ci`, so
every merge silently dropped Kilo's `postinstall` tail (`&& bun run
script/setup-git.ts`) and the `dev-setup` root shortcut, and it never
pruned upstream-only scripts (`dev:desktop` / `dev:web` / `dev:console`)
or upstream-only catalog entries (`@sentry/solid`,
`@sentry/vite-plugin`) whose target packages Kilo doesn't ship.
- replace the per-script if-blocks with data-driven PRESERVE_SCRIPTS
- add DELETE_UPSTREAM_SCRIPTS for scripts that reference packages Kilo
doesn't ship
- add DELETE_UPSTREAM_CATALOG for catalog entries with zero Kilo consumers
- apply the same policy in both transformPackageJson (conflict path) and
transformAllPackageJson (pre-merge sweep path) — previously the
pre-merge sweep was missing `changeset` / `changeset:version`
preservation
- new tests covering preservation, deletion, opencode test scripts, and
the catalog pruning
The automated kilo compat transform keeps upstream's root scripts/catalog
wholesale and only re-applies a handful of Kilo-specific scripts, which
silently dropped:
- postinstall's `&& bun run script/setup-git.ts` tail (needed to set
merge.conflictStyle=zdiff3 locally, which upstream merges rely on)
- the `dev-setup` script shorthand
- kept dead `dev:desktop` / `dev:web` / `dev:console` scripts whose
target packages aren't tracked in Kilo
- kept `@sentry/solid` / `@sentry/vite-plugin` catalog entries that
have zero consumers in our tree
When the consumer (readLines) hits the line/byte cap and destroys the
PassThrough, the underlying createReadStream had no link back and would
keep reading chunks to EOF in the background, defeating the early-exit
optimisation for large files.
Optimistically stream the file as UTF-8 -- the common case -- using a
fatal-mode TextDecoder so the read tool can stop pulling bytes from
disk once the line / 50KB byte cap is hit. Only fall back to a
full-buffer iconv decode when the bytes turn out not to be valid UTF-8.
The streaming + retry logic lives in a new kilo helper
(packages/opencode/src/kilocode/text-stream.ts) so the read tool's
`lines` function stays close to upstream OpenCode shape.
The existing apply_patch encoding test only checked final file bytes,
which were correct because Patch.deriveNewContentsFromChunks does its
own encoding-aware read. The diff and additions/deletions counts
returned to the user (and shown in the permission prompt) were
nonetheless garbled because the surrounding tool reused a hard-coded
UTF-8 decoder. Pin the diff metadata to catch that regression.
Bom.readFile uses a hard-coded UTF-8 TextDecoder, so the oldContent
captured for the diff, additions/deletions counts, and permission-prompt
metadata was mojibake for any non-UTF-8 file. The actual bytes written
were correct because deriveNewContentsFromChunks already does
encoding-aware reads, but the user-visible diff did not reflect the real
file contents. Switch to EncodedIO.read to match.
Mark IJbema