Improving the Nextjs/JS analyzers

[chinmaypant21]

I was testing noir against some real Next.js codebases and noticed a few things on the JS/TS / Next.js analyzers. Wanted to check these before opening issues/PRs. Roughly ordered by how self-contained I think they are.

1. Commented-out code is treated as live
Lines starting with // (and /* */ blocks) still get analyzed, so commented-out handlers/headers show up as real endpoints. Feels like it belongs in a shared JS/TS lexer since other analyzers might hit the same thing (I didn't check tho).

2. Variable header keys get dropped
req.headers["stripe-signature"] works, but req.headers[SIGNATURE_HEADER] doesn't . I believe it's more informative to surface the identifier and mark it "unresolved" than droping it.

3. formData bodies render as a=&b=&c=
For formData.get("file") etc., the body prints as file=&description=&folder=, which reads like empty query params. Empty values are fine but I believe showing this as a searchParam isn't the most ideal way. Could we preserve the source/content-type? (Separate Q: is the a=&b=&c= body rendering intentional?

4. Server Actions show as POST /actionName
Server actions aren't real URL routes, so POST /actionName is a bit misleading and can't be grep'd in the sourcecode. Some action-specific representation might fit better (e.g. POST [action] banUser). Also: direct JS args (banUser(userId: string, reason: string)) appear in -f json but not in console output, which looks like a console-formatter gap.

I'd love to know your opinion for this and would be glad to help resolving them :)

[hahwul]

@chinmaypant21
Thanks for testing on real Next.js codebases and sharing the feedback. Appreciate it.
Most of these points make sense. Quick thoughts:

• Commented-out code being analyzed as live: Yeah, that's not ideal. Skipping comments in the JS/TS parser would be better, and a shared lexer approach sounds reasonable.
• Variable header keys getting dropped: Good catch. Surfacing them as unresolved instead of dropping them would be clearer.
• formData bodies rendering as a=&b=&c=: Not the cleanest. Preserving content-type or the original form info would be nicer.
• Server Actions showing up as regular POST routes: This one is a bit tricky. Representing them differently and showing the JS signature in console output both seem like useful improvements.

These feel worth tracking as separate issues. Want to open them yourself, or should I create the issues? And if you want to take any of them for a PR, feel free. Happy to review.

Thanks again :D

[chinmaypant21]

Thanks for the feedback @hahwul . I'll create the issues for the same, and pick a few (or all) of them gradually :)

[hahwul]

@chinmaypant21
Thank you! Would you like me to assign these issues to you?

[chinmaypant21]

Sure :)