Hey folks, been running FOSSA for about six months now, and we just finished rolling it out to the entire dev team — roughly 100 engineers working in our TypeScript/Go monorepo. Overall, it's been a game-changer for license compliance and SBOM generation, but wow, the monorepo setup really threw us some curveballs. 😅
I figured I'd share what actually broke or needed serious tuning, hoping it saves someone else a weekend.
* **Scan times went through the roof on the first run.** The default configuration tried to analyze every package.json and go.mod in the entire tree as if they were independent projects. We saw scans taking over 90 minutes, which totally broke our CI feedback loop. The key was switching to a **monorepo-aware analysis mode** and using `.fossa.yml` files at the root of key service directories to define modules properly.
* **False positives on internal packages.** Our shared internal libraries were being flagged as "unlicensed" or pulled from the wrong VCS location. We had to manually define dependencies in the FOSSA project config to mark them as internal and exempt them from certain policies.
* **The "deep" vs "shallow" dependency resolution debate.** For our Go services, the deep analysis was creating massive, noisy reports because of the way the toolchain fetches dependencies. We ended up setting shallow scans for Go and reserving deep scans only for our frontend npm packages, which needed the full tree for audit purposes.
On the plus side, once we got the configuration dialed in, the integration with our PR checks is fantastic. It's catching incompatible licenses on new dependencies before they get merged, which is exactly what we wanted.
Has anyone else hit similar issues with a large monorepo? I'm especially curious if you found a better way to handle the performance tuning for mixed-language repos.
—Chris
K8s enthusiast
Oh yeah, the internal packages one is such a classic headache! We had the same issue where FOSSA kept trying to fetch our shared `@company/utils` package from a public registry. Our fix was a bit different though - we ended up using the `experimental: allow-unresolved: true` flag in our `.fossa.yml` and then explicitly listing those internal packages in a custom policy. It feels a bit hacky, but it stopped the false alarms.
The scan time problem is brutal. Even after switching modes, we found we had to aggressively prune which directories were considered for analysis. Did you guys set up any custom excludes for things like `node_modules` inside nested `packages/` or `dist` folders? I'm curious if your config looks similar to ours now.
Integration Ian
The jump to 90 minute scan times is a huge cost multiplier in cloud CI environments. That's a lot of compute time burning money while everyone waits.
We hit a similar wall and found the monorepo mode helped, but the real fix was restructuring the analysis to run only on changed paths in our PRs. We use a custom script with `git diff` to identify which service directories had modifications, then only run FOSSA on those. It cut our average scan time down to under 7 minutes and saved about $1400 a month on our CI bill.
Did you consider a targeted, diff-based approach, or was setting the global analysis mode sufficient for your team?
CloudCostHawk
Yep, the monorepo mode was a lifesaver for us too. The internal packages issue is still a bit of a pain though, even with manual definitions in the project config. We've found we have to update it pretty much every time someone spins up a new internal lib, which is a chore.
I'm curious about your last point - what was the outcome of the deep vs shallow resolution debate for your team? We went with shallow to keep scans fast, but I sometimes wonder if we're missing something in the nested deps.
Self-host or die trying.