Watch dependency tracking misses static re-exports

[bcomnes]

Summary

DOMStack inherits an upstream dependency-analysis limitation: static re-exports are not followed. This can leave watch output stale, including retained global-data indexes introduced in #326 (implementing #325). We are deliberately accepting this limitation for now and removing the custom analyzer workaround from that PR. An upstream fix will be pursued separately.

Verified upstream behavior

Reproduced with @11ty/dependency-tree-typescript 1.0.0, which delegates to @11ty/dependency-tree-esm 2.0.4. Current upstream main at 8b9a03ca2ba0650d9732e8fea9b86ac53947dd09 has the same limitation: its getSources loop handles ImportDeclaration but not ExportNamedDeclaration or ExportAllDeclaration.

• ESM implementation: https://github.com/11ty/eleventy-utils/blob/8b9a03ca2ba0650d9732e8fea9b86ac53947dd09/parse-deps-esm/main.js#L75-L88
• TypeScript wrapper: https://github.com/11ty/eleventy-utils/blob/8b9a03ca2ba0650d9732e8fea9b86ac53947dd09/parse-deps-typescript/index.js

Minimal reproduction

Create leaf.js containing:

export const value = 1;

Create barrel.js containing:

export { value } from "./leaf.js";

Run the installed analyzer:

import { find } from "@11ty/dependency-tree-typescript";
console.log(await find("./barrel.js"));

Expected: the result includes leaf.js. Actual: an empty array. The same failure occurs with export * from and export * as namespace from. If a root imports barrel.js, the result includes the barrel but omits its re-exported leaf.

DOMStack impact

A global.data.ts producer may import a barrel that re-exports a title formatter. If that formatter is also directly imported by a template, editing it can schedule a template build without identifying the global-data dependency. The incremental callback can then receive a delta with no affected source pages and reuse records produced by the old formatter. Re-running the callback alone does not refresh those cached records. Ordinary watch dependency tracking is affected too; this is not exclusive to incremental global data.

Temporary workaround

Use an explicit import followed by a local export rather than a re-export:

import { value } from "./leaf.js";
export { value };

Alternatively, restart watch after editing inputs reached through re-exports. A fresh build does not reuse the retained index.

Follow-up

• Fix runtime re-export dependency traversal upstream, including transitive named, star, and namespace re-exports.
• Preserve import attributes and distinguish runtime dependencies from declaration-level TypeScript type-only exports.
• Upgrade DOMStack to the fixed upstream release rather than maintaining a custom parser adapter.
• Add regression coverage for a re-exported leaf shared by a source page or global-data producer and another template/browser role; compare watch output with a fresh build.

No matching re-export issue or fix was found when checking the current and former upstream repositories. Related reports are 11ty/buildawesome#3899 (nested config hot reload, closed) and 11ty/eleventy-utils#6 (TypeScript parsing, closed), but neither resolves this re-export limitation.