I've been evaluating Mend's VS Code extension for the last three weeks as part of a broader tooling audit, and I have to say the stability is subpar. The plugin has crashed or become unresponsive on four separate occasions during normal scanning operations, requiring a full IDE restart to restore functionality. This is on a clean, dedicated testing environment, not a cluttered development machine.
My setup is as follows, which should rule out typical resource conflicts:
- **VS Code Version:** 1.89.1 (user setup)
- **Mend Extension Version:** 23.10.4.0
- **OS:** Windows 11 Pro, 22H2 (Build 22621.2861)
- **System Resources:** 32GB RAM, 12-core CPU, ample free disk space
- **Project Type:** Medium-sized JavaScript monorepo (~1500 dependencies)
The crashes appear correlated with two specific actions, though I haven't established definitive causality yet:
1. Triggering a manual scan on the entire workspace root while a previous scan is still processing.
2. Navigating through the vulnerability list in the Mend sidebar immediately after a scan completes.
The error logged in the Developer Console (Help > Toggle Developer Tools) is consistently a JavaScript heap out-of-memory error, which suggests the plugin is not managing its memory footprint effectively during result aggregation or UI rendering.
```
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF6F80E04EF napi_wrap+109135
2: 00007FF6F8086BB6 public: bool __cdecl v8::internal::CPUProfiler::StartProfiling(class std::basic_string<char,struct std::char_traits,class std::allocator > const &,bool,class v8::internal::CPUProfilingOptions)+64982
```
I've attempted the standard remediation steps: reinstalling the extension, clearing VS Code's cache, and increasing the Node.js heap limit via environment variables (`NODE_OPTIONS=--max-old-space-size=8192`). The last measure delayed the crash but did not prevent it.
Before I dive deeper into profiling the extension's runtime behavior, I want to see if this is a localized issue or a wider pattern. Has anyone else encountered similar instability with the Mend VS Code plugin, particularly on larger codebases? If so, have you identified any workarounds or configuration changes that improve reliability beyond what I've listed? Concrete details about your environment, project scale, and the crash trigger would be most useful for comparison.
Show me the benchmarks
I'm a junior dev at a small e-commerce agency, and we use Mend's SCA scanning in our Shopify app projects. I don't run it in VS Code in production, but I've tested both the VS Code plugin and their CLI for our CI pipeline.
Since you're auditing, here's a breakdown from someone who also had to pitch a tool:
**Fit and Target:** They're aimed squarely at mid-market and up. Everything from their sales process to feature set feels built for a security team. For a small shop like ours, it's overkill and that shows in the plugin complexity.
**Real Pricing:** It's not cheap for smaller teams. We're on a special "startup" plan, but the list price we saw started around $5k/year minimum. The real hidden cost is the time to properly configure the policy rules and false-positive management.
**Deployment Effort:** The CLI tool is stable and integrates cleanly into a GitHub Actions workflow (took an afternoon). The VS Code plugin, as you're finding, feels like a bolted-on afterthought. It's trying to do too much real-time analysis in the IDE itself.
**Where It Breaks:** The VS Code plugin is the weak link. It's memory-hungry, exactly as you've seen. On my mid-tier MacBook, it chokes on anything over a few hundred dependencies if I try to do a full workspace scan. It's fine for incremental file scanning, but the full-scan feature is basically unusable.
My recommendation depends on your actual goal. If you need real-time, in-IDE findings for developers, I'd honestly look at Snyk's VS Code extension - it felt more polished in my testing. If your primary need is reliable, automated scanning in CI/CD for compliance, then Mend's CLI is solid and I'd recommend it for that, but tell your team to skip the unstable plugin.
What's the main driver for your audit - is it more about developer experience or enforcing policy gates in the build process? That would make the call clean.