@young1lin/dsh-ui-gitworkbench 0.1.14 → 0.1.16

package/lib/dir-listing.js

@@ -0,0 +1,34 @@
+/**
+ * One lazily listed directory, shaped for the wire.
+ *
+ * The Files tab browses ignored directories by reading them from the
+ * filesystem ONE level at a time — git cannot do this scoped: a pathspec
+ * under `--directory` still collapses the whole ignored directory to a
+ * single line, and dropping `--directory` would enumerate every file inside
+ * `node_modules` at once. A `readdir` is one level by construction, costs
+ * milliseconds, and says what a browser wants to know: what is HERE.
+ *
+ * Only the shaping is pure (ordering, capping); the read itself stays in
+ * `index.ts`, which vitest cannot load. Same split as `fs-remove.ts`.
+ *
+ * @module @young1lin/dsh-ui-gitworkbench/dir-listing
+ */
+/** The most entries one expansion returns. A real directory level is a few
+ *  hundred at most (`node_modules`'s own top level); a cap beyond that is a
+ *  reported fuse against a pathological directory, not a working number. */
+export const DIR_CHILD_CAP = 5_000;
+/**
+ * Order and cap raw readdir results: directories before files (the shape
+ * every file tree has, matching `treeRows`), each run by name, and a cut
+ * REPORTED rather than silent.
+ *
+ * @param raw - the directory's entries with their best-known dir-ness
+ *              (symlinks already resolved by the caller).
+ * @param cap - most entries to return.
+ */
+export function shapeDirChildren(raw, cap = DIR_CHILD_CAP) {
+    const byName = (a, b) => a.name.localeCompare(b.name);
+    const ordered = [...raw.filter(entry => entry.dir).sort(byName), ...raw.filter(entry => !entry.dir).sort(byName)];
+    const truncated = ordered.length > cap;
+    return { entries: truncated ? ordered.slice(0, cap) : ordered, truncated };
+}

package/lib/fs-remove.js

@@ -6,8 +6,8 @@
  * `git clean` refuses paths it cannot index, which on Windows includes every
  * reserved device name (`nul`, `con`, `aux`, `com1`, and the same names with
  * any extension). So the removal goes through the filesystem, where git's own
- * refusal to leave the repository does not apply — hence the checks here
- * rather than a bare `rm`.
+ * refusal to leave the repository does not apply — hence the path lock in
+ * `path-lock.ts` rather than a bare `rm`.
  *
  * Lives outside `index.ts` so vitest can load it: the class there needs the
  * dsh runtime, and the property worth testing is "what does this delete, and
@@ -16,36 +16,7 @@
  * @module @young1lin/dsh-ui-gitworkbench/fs-remove
  */
 import { rm } from 'node:fs/promises';
-import { resolve, sep } from 'node:path';
-import { isSafeRelativePath } from './discard-ops.js';
-/**
- * Resolve a repo-relative path against the worktree root, refusing to leave it.
- *
- * The second lock rather than the only one: {@link isSafeRelativePath} already
- * rejected traversal spellings when the plan was made. This re-checks the
- * RESOLVED path, which is the form the filesystem acts on, so a path that
- * survives the first check by being spelled unusually still has to land inside
- * the root to be acted on.
- *
- * @param root - the worktree directory, absolute.
- * @param relative - repo-relative path from a plan step.
- * @returns the absolute path to act on.
- * @throws if the path is not a safe relative path, resolves outside the root,
- *         or IS the root.
- */
-export function resolveInside(root, relative) {
-    if (!isSafeRelativePath(relative)) {
-        throw new Error(`unsafe path to delete: ${JSON.stringify(relative)}`);
-    }
-    const base = resolve(root);
-    const target = resolve(base, relative);
-    if (target === base)
-        throw new Error('refusing to delete the worktree root');
-    if (!target.startsWith(base + sep)) {
-        throw new Error(`refusing to delete outside the worktree: ${JSON.stringify(relative)}`);
-    }
-    return target;
-}
+import { resolveInside } from './path-lock.js';
 /**
  * Remove one entry from the worktree, having proven it is inside it.
  *
@@ -60,10 +31,8 @@ export function resolveInside(root, relative) {
  * `force` makes an absent entry a success: the reader asked for it to be gone,
  * and it is.
  *
- * A symlinked directory inside the worktree could still point outward; that is
- * a repository someone already has write access to, and resolving link targets
- * per segment on every delete would cost a stat per segment for a case git
- * itself does not defend against.
+ * A symlinked directory inside the worktree could still point outward — the
+ * limit of a lexical resolve, stated where the lock is.
  *
  * @param root - the worktree directory, absolute.
  * @param relative - repo-relative path from a plan step.