Skip to content

fix: resolve symlinks when checking entrypoint in isMain#666

Open
annajowang wants to merge 1 commit into
mainfrom
fix-symlink-ismain
Open

fix: resolve symlinks when checking entrypoint in isMain#666
annajowang wants to merge 1 commit into
mainfrom
fix-symlink-ismain

Conversation

@annajowang

Copy link
Copy Markdown
Collaborator

Fixes a bug where symlinked binaries in node_modules/.bin evaluate to false in isMain checks (because process.argv[1] is a symlink path), preventing the build script from executing.

@wiz-9635d3485b

wiz-9635d3485b Bot commented Jul 8, 2026

Copy link
Copy Markdown

Wiz Scan Summary

Scanner Findings
Vulnerability Finding Vulnerabilities -
Data Finding Sensitive Data -
Secret Finding Secrets -
IaC Misconfiguration IaC Misconfigurations -
SAST Finding SAST Findings 2 Low
Software Management Finding Software Management Findings -
Total 2 Low

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the isMain utility function in both the Angular and Next.js adapters to resolve process.argv[1] to its real path using fsExtra.realpathSync inside a try-catch block. The reviewer suggested also resolving the second path (fileURLToPath(meta.url)) to its real path to ensure robust comparison when modules are loaded via symlinks, which is common in monorepos.

if (!process.argv[1]) return false;
return process.argv[1] === fileURLToPath(meta.url);
try {
return fsExtra.realpathSync(process.argv[1]) === fileURLToPath(meta.url);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To ensure maximum robustness, both paths should be resolved to their real paths. If the module itself is loaded via a symlink (which is common in monorepos or when running with --preserve-symlinks), fileURLToPath(meta.url) might return the symlinked path rather than the real path, causing the comparison to fail. Resolving both sides with fsExtra.realpathSync guarantees a correct comparison of the actual physical files on disk.

Suggested change
return fsExtra.realpathSync(process.argv[1]) === fileURLToPath(meta.url);
return fsExtra.realpathSync(process.argv[1]) === fsExtra.realpathSync(fileURLToPath(meta.url));

if (!process.argv[1]) return false;
return process.argv[1] === fileURLToPath(meta.url);
try {
return fsExtra.realpathSync(process.argv[1]) === fileURLToPath(meta.url);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

To ensure maximum robustness, both paths should be resolved to their real paths. If the module itself is loaded via a symlink (which is common in monorepos or when running with --preserve-symlinks), fileURLToPath(meta.url) might return the symlinked path rather than the real path, causing the comparison to fail. Resolving both sides with fsExtra.realpathSync guarantees a correct comparison of the actual physical files on disk.

Suggested change
return fsExtra.realpathSync(process.argv[1]) === fileURLToPath(meta.url);
return fsExtra.realpathSync(process.argv[1]) === fsExtra.realpathSync(fileURLToPath(meta.url));

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants