.gitignore (1)

37-42: Consider gitignoring bundle-viz/src/bundle-data.json.

scripts/generate-bundle-data.ts writes its output directly to bundle-viz/src/bundle-data.json. Without a gitignore entry, developers who run npm run generate-bundle-data will have that generated file show up as a dirty working tree and could accidentally commit real bundle data alongside a PR. If the intent is to ship only a committed placeholder and treat generated output as local-only, adding the pattern prevents accidental commits.

💡 Proposed addition

 # bundle-viz app: dependencies and build artifacts
 bundle-viz/node_modules
 bundle-viz/dist
+
+# bundle-viz generated data (run `npm run generate-bundle-data` locally)
+bundle-viz/src/bundle-data.json

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.gitignore around lines 37 - 42, Add the generated
bundle-viz/src/bundle-data.json to .gitignore so running
scripts/generate-bundle-data.ts (which writes that file) doesn't leave a dirty
working tree or risk accidental commits; update the .gitignore by adding the
pattern "bundle-viz/src/bundle-data.json" (or a broader "bundle-viz/src/*.json"
if preferred) alongside the existing bundle-viz entries to ensure generated
bundle data files are ignored.

scripts/treeshaking-groups/BarStack.ts (1)

1-1: Remove orphaned comment.

/** The component being imported */ on Line 1 is not attached to any declaration and has no equivalent in any other treeshaking-groups file. It looks like a leftover template artifact.

🧹 Suggested cleanup

-/** The component being imported */
-
 /**
  * All components expected to appear in the bundle when importing this component.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/treeshaking-groups/BarStack.ts` at line 1, Remove the orphaned
leading JSDoc comment `/** The component being imported */` from the top of
scripts/treeshaking-groups/BarStack.ts; this comment is not attached to any
declaration (no matching symbol like a function/class/variable in BarStack) and
should simply be deleted to clean up the file.

bundle-viz/vite.config.ts (1)

1-20: LGTM — optional: prefer import.meta.url over __dirname for ESM portability.

The difference between __dirname and import.meta.url in Vite configs is that modern Vite projects use ES modules where __dirname isn't natively available. Vite does inject CJS shims when processing its config file so this works today, but the idiomatic ESM-safe alternative avoids the dependency on Vite's shim injection:

♻️ Optional: modern ESM-safe equivalent

-import { resolve } from 'path';
+import { fileURLToPath, URL } from 'node:url';
 
 export default defineConfig({
   resolve: {
     alias: {
-      recharts: resolve(__dirname, '../src'),
+      recharts: fileURLToPath(new URL('../src', import.meta.url)),
     },
   },

Also note that bundle-viz/tsconfig.json maps recharts to ../src/index.ts (explicit file entry) while this config maps to ../src (directory). The manual approach requires you to sync aliases between tsconfig.json and vite.config.ts; if you ever add more aliases, you'll need to update both files. Both resolve identically for import from 'recharts' in practice, but keeping them consistent avoids confusion.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@bundle-viz/vite.config.ts` around lines 1 - 20, Replace the CommonJS
__dirname usage with an ESM-safe import.meta.url-based path for the recharts
alias: change the alias value from resolve(__dirname, '../src') to resolve(new
URL('../src', import.meta.url).pathname) (or derive __dirname via
fileURLToPath(import.meta.url) if you prefer), and ensure this alias remains
consistent with the tsconfig.json mapping for recharts (currently
../src/index.ts) so both configs resolve the same module entry.

scripts/treeshaking-groups/CartesianGrid.ts (1)

1-1: Orphan comment — appears to be a leftover template fragment.

Line 1 (/** The component being imported */) doesn't annotate any declaration. The meaningful documentation is already in the block comment on lines 3–6. Consider removing it.

Proposed fix

-/** The component being imported */
-
 /**
  * All components expected to appear in the bundle when importing this component.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/treeshaking-groups/CartesianGrid.ts` at line 1, Remove the orphan
top-of-file JSDoc comment "/** The component being imported */" which does not
annotate any declaration and duplicates existing documentation for
CartesianGrid; delete that stray comment at the very start of CartesianGrid.ts
so only the meaningful block comment (lines documenting the CartesianGrid
component) remains.

bundle-viz/README.md (1)

40-47: Add a language identifier to the fenced code block.

The markdownlint tool flags this block (MD040). Use ```text for plain directory listings.

Proposed fix

-```
+```text
 bundle-viz/
   package.json        standalone Vite + React app
   vite.config.ts      aliases recharts → ../src so no build step is needed
   src/
     App.tsx           chart components and layout
     main.tsx          React entry point
     bundle-data.json  placeholder shipped in git; overwritten by npm run generate-bundle-data
-```
+```

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@bundle-viz/README.md` around lines 40 - 47, Markdown linting flags the fenced
code block under the bundle-viz directory listing for missing a language
identifier; edit the README.md section showing the directory tree and change the
opening fence from ``` to ```text (i.e., add the "text" language identifier for
that directory listing block) so the block becomes ```text ... ``` and satisfies
MD040.

scripts/generate-bundle-data.ts (1)

111-111: Consider ensuring the output directory exists before writing.

If bundle-viz/src/ is ever missing (e.g., after a partial clone or clean), this will throw. A one-liner guard would make the script more robust.

Proposed fix

+  fs.mkdirSync(path.dirname(outFile), { recursive: true });
   fs.writeFileSync(outFile, JSON.stringify(bundleData, null, 2), 'utf-8');

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/generate-bundle-data.ts` at line 111, The script currently calls
fs.writeFileSync(outFile, ...) which will throw if the target directory (e.g.,
bundle-viz/src/) is missing; before calling fs.writeFileSync, ensure the parent
directory exists by creating it (use the directory from path.dirname(outFile))
with recursive directory creation (e.g., fs.mkdirSync(..., { recursive: true }))
so the write is robust even after a clean/partial clone.

scripts/treeshaking.ts (1)

165-176: Static analysis ReDoS warnings are low-risk here, but escapeRegExp would be a cheap safety net.

The name values originate from ProjectDocReader.getAllRuntimeExportedNames() — valid JS identifiers that cannot contain regex metacharacters. So the ReDoS concern flagged by ast-grep is a false positive in practice. That said, since matchComponentNamesInBundle is a public export, a simple escape (or switching to sourceCode.includes(...) with template strings) would make it defensively safe without a performance cost.

Optional hardening

+function escapeRegExp(s: string): string {
+  return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+}
+
 export function matchComponentNamesInBundle(sourceCode: string, componentNames: ReadonlyArray<string>): Set<string> {
   return new Set(
     componentNames.filter(name => {
+      const escaped = escapeRegExp(name);
       return (
-        new RegExp(`var ${name} `).test(sourceCode) ||
-        new RegExp(`const ${name} `).test(sourceCode) ||
-        new RegExp(`function ${name}\\(`).test(sourceCode) ||
-        new RegExp(`class ${name}\\s+{`).test(sourceCode)
+        new RegExp(`var ${escaped} `).test(sourceCode) ||
+        new RegExp(`const ${escaped} `).test(sourceCode) ||
+        new RegExp(`function ${escaped}\\(`).test(sourceCode) ||
+        new RegExp(`class ${escaped}\\s+{`).test(sourceCode)
       );
     }),
   );
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/treeshaking.ts` around lines 165 - 176, matchComponentNamesInBundle
builds RegExp objects from unescaped component names which triggers static ReDoS
warnings; defensively escape the identifier before constructing the RegExp (or
replace the RegExp checks with simple string checks using sourceCode.includes
for patterns like `var ${name} `, `const ${name} `, `function ${name}(` and
`class ${name} `). Update matchComponentNamesInBundle to call a small escape
function (e.g. escapeRegExp) on the name or switch each test to
sourceCode.includes so inputs from ProjectDocReader.getAllRuntimeExportedNames
are safely handled and the ast-grep warning is eliminated.

scripts/trace-bundle.ts (1)

50-82: BFS can explore exponentially many paths on dense graphs.

The search clones and enqueues a new path array for every edge and only prunes cycles within a single path (line 75). On a heavily interconnected module graph this could cause the queue to grow very large before hitting maxResults. For a dev tool this is likely acceptable given MAX_DEPTH = 25 and maxResults = 8, but if performance is ever an issue, consider a level-limited BFS with a global visited set for single-shortest-path, then re-running with relaxed constraints for alternate paths.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@scripts/trace-bundle.ts` around lines 50 - 82, findShortestPaths currently
clones and enqueues a full path for every edge which can explode on dense
graphs; instead implement a two-phase approach inside findShortestPaths: (1) do
a level-limited BFS using a global visited/distance map (use MAX_DEPTH and stop
when endId is discovered) to compute shortest distance(s) from startId to every
node without storing whole paths, and (2) perform a bounded backtracking/DFS
from startId that uses the distance map to only follow edges that lead closer to
endId and collect up to maxResults paths (this avoids enqueuing every
intermediate path and reduces queue growth caused by pushing [...currentPath,
next] for each importedId). Use the existing names nodeById, queue/MAX_DEPTH,
node.importedIds and maxResults to locate where to change logic.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro