Stacked on #140, so the diff here is just the workflow change.

Node 26 is the current release line (26.6.0, released 2026-08-03) and
becomes LTS in October. Running it now surfaces breakage before the
promotion rather than after.

`engines` stays at `>= 18`, so this only widens what CI covers.

Backport of #140 to 1.x.

`isRealPathSafe()` stopped walking as soon as `realpath()` failed on a
dangling link, checking only that link's immediate target. A destination
reached through several hops, or through a linked directory, was only
partially resolved, so an entry could land somewhere the check had not
accounted for.

It now resolves the remaining hops itself, bounded by
`MAX_SYMLINK_DEPTH`, and walks from whichever extraction root actually
contains the target so a link named in the real namespace is not
rejected.

Behaviour change worth noting: a file entry landing on a symlink now
replaces that link instead of writing through to whatever it points at.
This matches tar(1), node-tar and libarchive. Where the platform has it,
the write also opens with `O_NOFOLLOW`. Linked directories inside the
extraction directory are still traversed.

Written in the callback style the surrounding 1.x code uses, so it stays
compatible with the branch's Node range. Suite is 166 passing on this
branch.

[skip ci]

## <small>1.10.6 (2026-08-05)</small>

* fix: resolve symlink chains fully when extracting (#142) ([90b2e54](90b2e54)), closes [#142](#142) [#140](#140)
* chore: replace var with let/const in isRealPathSafe (#135) ([60fa3af](60fa3af)), closes [#135](#135)

[skip ci]

## <small>2.1.2 (2026-08-05)</small>

* test: use node:crypto randomUUID instead of uuid dependency (#143) ([c0d269f](c0d269f)), closes [#143](#143) [#139](#139)
* ci: add Node.js 26 to the test matrix (#141) ([5c725e6](5c725e6)), closes [#141](#141) [#140](#140)
* fix: resolve symlink chains fully when extracting (#140) ([72a3c84](72a3c84)), closes [#140](#140)

….3.1 (#145)

Fixes the Node 26 CI failure on master, and moves both zip dependencies
to their upstream, maintained versions.

## yauzl: the Node 26 fix

`@eggjs/yauzl` depends on `fd-slicer2`, whose `ReadStream` loses data
when piped on Node 26. Any zip entry over the 64 KiB `highWaterMark`
delivers roughly the first chunk and then stalls, with no `end`, no
`error`, no `close`. That is why `zip.uncompress()` hangs until the 60s
timeout on Node 26 while passing on 18 through 24.

Not our code: released 2.1.1 reproduces it identically. Reported
upstream at node-modules/yauzl#3.

`yauzl@3.4.0` dropped `fd-slicer` entirely (only dependency is now
`pend`) and does not have the bug.

The fork was adopted for `decodeStrings: false` so absolute paths
survive `validateFileName`. I checked that still holds against the
`contain-absolute-path.zip` fixture rather than assuming:

| | @eggjs/yauzl 2.11.0 | upstream 3.4.0 |
| --- | --- | --- |
| entries | 31 | 31 |
| `fileName` is Buffer | 31 | 31 |
| `externalFileAttributes` present | 31 | 31 |
| files read | 21 | 21 |
| leading `/` entry | preserved | preserved |

Only visible difference: yauzl 3 capitalises the "End of central
directory record signature not found" message, so that assertion is now
case-insensitive.

## yazl 3 and the early-finalize bug it exposed

yazl 3 turns "add entries after calling `end()`" from a tolerated no-op
into a thrown error, and compressing trips it immediately.

`_onEntryFinish()` finalizes as soon as the entry queue is momentarily
empty. For zip the finish callback runs synchronously, so a caller
doing:

```js
zipStream.addEntry(streamA, ...);
zipStream.addEntry(bufferB, ...);
```

closed the archive after the first entry, and the second threw. Tar
avoids it only because its `fs.stat` makes the callback async, which
lets the later entries queue first.

Worth being precise about the old behaviour: **yazl 2 did not drop those
entries.** I checked, and the produced archive contained all of them. So
this was latent, not a live data-loss bug.

Fix is to finalize on the next tick and skip it if an entry arrived
meanwhile. Verified the produced archive still contains every entry.

Residual limitation, unchanged in spirit from before: entries added
after a longer async gap still finalize early. That is the existing
drain heuristic, and giving the stream an explicit "done adding" call
would be an API change worth doing separately.

## Result

**171 passing on both Node 24 and Node 26**, lint and `tsc` clean. On
Node 26 the zip suite finishes in ~495ms where it previously hung for
60s. The symlink cases from #140 were re-checked through the new zip
path and still block.

Drops `fd-slicer2` and `buffer-crc32` from the tree. Supersedes #132.

[skip ci]

## <small>2.1.3 (2026-08-05)</small>

* fix: replace @eggjs/yauzl with upstream yauzl 3.4.0, update yazl to 3.3.1 (#145) ([572a0ba](572a0ba)), closes [#145](#145) [#140](#140)
* chore(deps): update dependency @types/node to v24 (#123) ([3499eb2](3499eb2)), closes [#123](#123)
* chore(deps): update dependency iconv-lite to ^0.7.0 (#122) ([e7ba2a5](e7ba2a5)), closes [#122](#122)