fix: derive a sensible torrent name when seeding an array of file paths

[mvanhorn]

Summary

Seeding an array of file path strings like client.seed(['index.html', 'package.json'], ...) now produces a torrent named after the files' common parent directory instead of the first file's basename, so file paths no longer come out as index.html/index.html.

Why this matters

Reported in #983 and re-validated by a member (ThaUnknown) in October 2024; the issue is labeled bug and accepted. The root cause is upstream of this repo's control flow: create-torrent's common-prefix detection skips string inputs (its input.forEach returns early for strings), so without opts.name it falls back to basename(firstStringPath). In a multi-file torrent that name becomes the bencoded info.name, i.e. the root folder, which prefixes every file path with the first file's name.

Changes

• WebTorrent.seed() in index.js already massages options for single string paths (opts.path = path.dirname(input)). This change extends that surface: when the input is an array of more than one path string and the caller passed no opts.name, it computes the common parent directory of the resolved paths and sets opts.name = path.basename(commonDir) — the same name seeding that folder directly would produce. If no meaningful common directory exists (filesystem root), options are left untouched and the existing create-torrent fallback applies. Caller-supplied opts.name and non-string inputs (Buffers, streams, Blobs, FileLists) are unaffected.

Testing

Added test/node/seed-array-paths.js: seeds two fixture paths as an array, asserts the torrent name is the shared parent directory's basename and that file paths inside the torrent are not nested under the first file's name; also covers the explicit opts.name override staying intact.

Fixes #983

[ThaUnknown]

this should be fixed by in createTorrent, not here

[mvanhorn]

Fair point, the name derivation does belong in create-torrent since that is where the torrent metadata is built, and webtorrent already delegates to it via the ^6.1.2 dep. I will port the fix there: derive the name from the array's common parent directory inside create-torrent, with the same test coverage, instead of patching index.js here. I will open a PR against create-torrent and link it back to this one. Do you want to keep this open as a tracking reference until that lands, or close it in favor of the create-torrent PR?

[mvanhorn]

Opened it: webtorrent/create-torrent#299. It derives the name from the files' common parent directory when seeding an array of path strings with no explicit name (the commonPrefix logic there only covered File/Blob objects), with a regression test and a green suite. Once that lands and releases, the workaround here can be dropped.

[github-actions]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?