Our team is currently evaluating FOSSA for enterprise-wide license compliance and vulnerability management, and we have encountered a significant operational blocker during the proof-of-concept phase. Specifically, the FOSSA CLI tool consistently hangs during the analysis phase of our primary TypeScript monorepo, which utilizes npm workspaces and contains over 500 discrete packages. The process fails to progress beyond "Analyzing dependencies..." for over 90 minutes before we terminate it, despite attempting multiple configurations.
We have systematically tested the following parameters without success:
* **Increased timeout and memory limits:** Setting `FOSSA_TIMEOUT` to 3600 and providing substantial memory headroom on the runner.
* **Analysis target refinement:** Attempting to scan the entire project root, as well as targeting specific subdirectories and individual `package.json` files.
* **Exclusion patterns:** Implementing a `.fossaignore` file to exclude `node_modules`, build artifacts, and non-production directories.
* **CLI versions:** Testing with both the latest stable release (3.9.1) and a previous version (3.8.4).
Given my focus on sales engagement and revenue operations tooling, I am accustomed to conducting thorough technical evaluations, and this blocker is preventing us from assessing FOSSA's core reporting and policy engine. The lack of verbose logging during the hang makes root cause diagnosis difficult.
I am seeking concrete workarounds or configuration insights from teams who have successfully onboarded large, complex monorepos. Specifically:
* Is there a documented, incremental scanning strategy for monorepos of this scale, perhaps by logically partitioning the dependency graph?
* Are there known performance issues with npm workspaces or specific transitive dependency patterns that require pre-processing?
* Has anyone successfully integrated the analysis step into a more granular CI/CD pipeline, per package or per service, and then re-aggregated results?
Any guidance on achieving a successful initial scan would be invaluable, as our subsequent evaluation hinges on the quality of the dependency and license data we can feed into FOSSA's policy and reporting workflows.
Method over hype
Hitting timeouts on 500+ packages isn't a config issue, it's a scale issue. The CLI's dependency resolution model likely can't handle your graph in one run.
We bypassed this for a large Go monorepo by splitting the analysis. Don't run `fossa analyze` at the root. Script it to run per logical service or workspace subdirectory, then aggregate the results. You'll need to manage the manifest file merging.
Also, check if your CI runner has network egress limits. FOSSA's backend calls can hang silently if outbound requests are throttled.
null
Totally agree on the split analysis approach. That's been our go-to for large SaaS implementations.
One caveat from our experience: the merge step for the results can get messy if your subdirectories have shared internal dependencies. You might see duplicate entries or conflict warnings that need manual cleanup in the final report. A bit of scripting to deduplicate after aggregation saved us hours.
The network egress point is also super valid - we've seen similar hangs in tightly controlled cloud environments. Sometimes it's not the CLI itself, but a proxy or firewall rule silently dropping the connection to FOSSA's API. Might be worth a packet trace.
Oh, the TypeScript monorepo detail is key here. The others mentioning split analysis are right, but with npm workspaces, you've got another layer of complexity.
The workspace hoisting can create a dependency graph that's a nightmare for a single-threaded analyzer. You might try running `fossa analyze` from the root of just one workspace, but even then, it'll likely crawl up to the root `package.json` and get stuck again.
For your POC, I'd suggest a blunt but effective script: temporarily comment out all but maybe 50 workspace definitions in your root `package.json`, run the analysis, then rotate. It's manual, but it'll prove whether the tool can actually process your deps at all before you invest in a fancy split-merge pipeline. If it still hangs on a small subset, then your problem is something else entirely, maybe network like others said.