Ignore the standalone CLI#20139
Conversation
Confidence Score: 5/5The change is a small, well-scoped fix that adds a single negated exclusion entry; the integration test directly validates the targeted behavior. The fix is minimal and correct: process.execPath reliably identifies the running binary on all platforms, the negated entry is applied in every code path that constructs a Scanner, and the new integration test exercises the exact failure scenario being addressed. No existing behavior is altered for users of the Node.js-based CLI. No files require special attention. Reviews (3): Last reviewed commit: "use windows binary directly" | Re-trigger Greptile |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughThe change excludes the running executable (process.execPath) from the scanner's source patterns by adding a negated source entry. A test copies the standalone CLI binary into the test workspace, runs it to produce CSS, and asserts the output contains no candidate utilities. CHANGELOG.md documents the fix. 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
b7ff21a to
53000f4
Compare
This PR fixes an issue where if you use the standalone CLI, and you move the standalone CLI into the current project, then we would scan that standalone CLI as-if it contains Tailwind CSS classes. Since the CLI contains actual Tailwind CSS classes, and is in fact readable text, this binary would've been used as a source.
There are a few ways of fixing this, we could hardcode all the known names, but that would result in an issue if you rename the CLI. We could check whether it's a binary format and look for magic numbers at the top. We could also check for a shebang at the top of the file and skip it that way.
While some of these solutions might still be useful for the future. For now I fixed it by essentially always ignoring
process.execPath. That way we never ever scan the actual executable regardless of whether you renamed it or not.Fixes: #20134
Test plan