Research: validate v0.3.2 with five real MSW projects

[felmonon]

Goal

Validate msw-inspector v0.3.2 with five independent, real MSW projects before prioritizing more scanner features.

This is not a benchmark and does not require publishing source code, private URLs, tokens, or full reports. Public-source exploratory trials are welcome and are tracked separately; they inform limitations but do not count toward the five owner/team validations.

Definition of done

• Five voluntary runs from independent MSW users or teams.
• Each run records only safe context: MSW major version, framework/test runner, Node version, and a redacted command/glob shape.
• Each participant records whether setup was clear, the reported totals, and any known false positive, false negative, or unsupported pattern.
• Every accuracy concern becomes a minimal safe reproduction or a linked issue; dynamic cases stay unsupported rather than guessed.
• A maintainer posts a short public decision summary naming the next evidence-backed improvement.

Safe run protocol

1. Install the released package in a branch or local checkout:

   npm install -D msw-inspector-cli@0.3.2

2. Start without a failing CI gate:

   npx msw-inspector --handlers "your-handler-globs" --sources "your-source-globs" --format json --report-file msw-inspector.json

3. Reply here or in Discussion #42 with the safe summary above. Do not attach private application code or unredacted reports.

Why this matters

Coverage tooling earns trust by being right on real projects. We will use these five runs to choose the next small accuracy improvement, not to add features blindly.

[lovewave02]

I ran the released msw-inspector-cli@0.3.2 locally against the public cloudflare/meet source as a reproducible trial. I am not a maintainer of that project, so please treat this as one public-source data point rather than an independent team validation if that distinction matters for #41.

Safe context: MSW ^2.3.5, Remix 2.11.1, Vitest 1.5.0, Node v22.23.1. I used the released package with explicit handler/source globs and no failing gate.

The report found 1 handler, 2 statically resolved API calls, 0 matches, 2 unmocked calls, 1 stale handler, and 8 unsupported dynamic calls. The most useful observation was that the project has a dynamic Calls API request path alongside http.post('https://rtc.live.cloudflare.com/apps/:appId/sessions/new', ...); because the URLs are runtime-derived, the tool leaves those calls unsupported and reports the handler stale. That seems safer than guessing, but it means this project should not use the result as a strict CI gate without review.

I kept the full report local and can provide a minimal redacted reproduction if that would help. Is this kind of public-source trial useful for the issue, or should I only report runs from projects I actively maintain?

[felmonon]

Thank you—this is useful and responsibly reported. Public-source trials are welcome; I’m recording this as a public-source exploratory trial, separate from the five owner/team validations.

The observed behavior matches the current conservative static model: runtime-derived call paths stay unsupported rather than guessed, so a related handler can appear stale when no statically resolved call reaches it. That means this project should not enable strict coverage or stale-handler gates without review; it is not evidence that the analyzer should guess a dynamic URL.

Please do not share the full report. A minimal redacted reproduction would help only if a statically resolvable call should have matched that handler, or if the documented limitation does not describe what you observed. Thank you for keeping the report local and for the precise context.