fix(sendFile): surface resolved path in "No such file" error; clarify no auto-versioning (#257)

[naorpeled]

Closes #257.

Background

#257 reported that a route /:v/schema.json returned {"error":"No such file"} when hitting /v1/schema.json, and asked for an option to disable versioning.

Investigation showed the premise doesn't hold: lambda-api has no automatic version routing or stripping — in the current code or anywhere in git history. Route matching (src/lib/request.js) is plain segment-by-segment traversal. Reproduced against the reporter's exact setup:

api.get('/:v/schema.json', (req, res) => res.json({ v: req.params.v }));
// GET /v1/schema.json  -> 200 { "v": "v1" }   ✅ already works

The "No such file" was not a routing error — it's emitted by res.sendFile() on ENOENT in the reporter's own handler (they most likely passed req.path = /v1/schema.json to sendFile, so the full path was looked up on disk). Because the error message was terse and pathless, it was easy to misread as a "versioning" problem.

So rather than add a no-op flag, this PR fixes the actual pain and locks in the behavior.

Changes

• src/lib/response.js — sendFile ENOENT errors now include the resolved path, e.g. No such file: ./test-missing.txt, so the real cause is self-evident. FileError already carried e.path; it just never reached the message.
• __tests__/versioning.unit.js (new) — regression tests proving version-like segments route literally (/v1/schema.json → params.v === 'v1'), a non-version segment behaves identically, an extra segment still 404s, and documents the base: 'v1' + leading :param collision caveat (→ 405).
• __tests__/sendFile.unit.js, __tests__/download.unit.js — updated the two "Missing file" assertions to the new message.
• README.md — documented that lambda-api does no automatic version handling, that base: 'v1' collides with a leading :param (prefer a non-version base + register({ prefix })), and how res.sendFile(path, { root }) resolves paths.

Heads-up for review

The error-message change surfaces the file path in the HTTP error body. It's helpful for debugging and mirrors Node's own ENOENT, but it is a minor change to a public error string — happy to make it opt-in or revert that part if you'd prefer it stay terse.

Verification

Full suite green: npm run build + tsd + 489 passed / 4 skipped across 28 suites. Prettier + ESLint clean on touched files.

[Copilot]

Pull request overview

This PR addresses confusion from issue #257 by clarifying that lambda-api does not do any automatic “version” path handling, and by making res.sendFile() missing-file errors more self-explanatory so they aren’t misread as routing failures.

Changes:

• Update sendFile() ENOENT handling to include the missing path in the "No such file" error message.
• Add a new regression test suite verifying version-like segments (e.g. /v1/...) are matched literally, plus a documented base: 'v1' caveat.
• Update README guidance and adjust existing unit tests to the new error string.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/lib/response.js	Changes ENOENT error message emitted by sendFile() to include a path string.
README.md	Documents that there is no automatic version stripping and clarifies sendFile({ root }) path resolution.
tests/versioning.unit.js	Adds regression tests for literal matching of version-like segments and base + leading :param collision behavior.
tests/sendFile.unit.js	Updates missing-file assertion to match the new error message.
tests/download.unit.js	Updates missing-file assertion to match the new error message.