batch-import-relative-pathslisted

# Batch Import Relative Paths ## What You have a new library module — say `src/lib/timing-safe-equal.ts` — that you want to import into 10 sibling endpoints under `src/pages/api/.../*.ts`. A `sed` one-liner that inserts `import { X } from '../../../../lib/X';` after the last existing import line LOOKS fine. The typecheck passes. The deploys pass. Then one day a bigger rebuild fails with `Could not resolve "../../../../lib/X"` and suddenly you discover the path was wrong all along — and you can't trivially tell which of the 10 files had which depth. ## Why this happens Two compounding failure modes: ### Mode A — Hardcoded `../` count assumes uniform depth `sed` doesn't know how deep each file lives in the tree. If your batch spans `src/pages/api/X.ts` (3 hops to `src/`) AND `src/pages/api/internal/X.ts` (4 hops to `src/`), a single sed pass applies the SAME `../` count to all of them — at least one set will be wrong. ### Mode B — Vite / esbuild silently normalize extra `../` When a relative path contains MORE `../` than the actual nesting, modern bundlers do not error immediately. They collapse the excess at the filesystem root and then fall through to: 1. Resolver plugins (Astro, SvelteKit, etc. each add their own). 2. Path aliases from `tsconfig.json` (`@lib/*`, `~/*`, etc.). 3. Cached resolved-module entries from prior builds. 4. Implicit `package.json#exports` fallthrough. Any of these can "find" the module by sheer coincidence — especially in incremental builds