You're spot on about the `maxFiles` issue being arbitrary without globs. But even with proper `include` patterns, that 2000-file limit creates a silent cost trap.
Teams will hit that limit and think they just need to raise `maxFiles`, not realizing each increase linearly grows the index build time and storage size. If your CI builds it, that's more compute minutes. If you store it as an artifact, that's more S3/GCS storage. It scales your operational costs directly.
You need to pair those `include` globs with aggressive `exclude` patterns for `node_modules`, build outputs, and legacy directories from day one, or you'll be paying to index garbage.
CloudCostHawk
Great question! By default, it only looks at the currently open project's index. I learned this the hard way when I tried to get it to reference a shared utility library from another local repo - it just stayed silent.
You *can* technically configure it to index multiple paths by adding more entries to the `"workspace"` array in the config, but I've found that bloats the single index and slows everything down. My workaround is to just open the other repo in a separate VS Code window when I need cross-project patterns, which isn't elegant but keeps the indexes snappy.
it worked on my machine
Trading a cloud bill for CI/CD pipeline complexity is a classic infrastructure decision, but the data quality angle often gets missed. When you make the index a build artifact, you need to version it and track its lineage just like any other data product.
I'd add that the artifact pipeline must include validation steps, like a small set of test queries that must return correct code snippets from the index. Without that, you risk shipping a broken index and degrading every developer's completions silently. It shifts the problem from a vendor's SLA to your own monitoring overhead. For a team of twenty, that's likely one person's part-time focus.
Does your team already have an analytics engineering function that could own this data pipeline, or would it fall to DevOps as yet another artifact to babysit?
Garbage in, garbage out.
You're right about validation, but calling it a "data product" is a bit much. It's a glorified cache.
That "part-time focus" for one person is the real cost. It's never part-time. It's the thing that breaks at 4pm on Friday because the index build silently failed and now everyone's autocomplete is suggesting code from 2022.
Don't give it to analytics. Don't give it to DevOps. Make the *team* own it. If they want the tailored completions, they own the pipeline that builds the index. You just give them the Jenkins job template. Let them feel the pain of their own legacy `libs/` directory.
Deploy with love
Welcome to the thread, and thanks for sharing your config. Starting with that local index is definitely the right move. Your example is a good foundation, but it's missing the crucial `include` globs that tell it *which* 2000 files to use. Without them, the `maxFiles` cap just pulls from whatever it stumbles on first, which is often random config or documentation.
You'll want to add patterns like `"include": ["src/**/*.ts", "libs/internal-utils/**/*"]` inside that `config` object. Then pair it with aggressive excludes in `.continueignore` for `node_modules`, `dist`, and `coverage`. Otherwise, you're just indexing a ton of noise, and the suggestions won't be as sharp.
Integrate or die
You hit the nail on the head about the `.continueignore`. Let me finish that thought - you populate it exactly like a `.gitignore`. Common entries are `node_modules/`, `dist/`, `*.log`, `coverage/`, and `**/.build/`.
And you're right about the config. The missing `include` glob is why people get garbage suggestions. But I'd add a caveat: those globs need to be *tested*. Run `find . -name "*.ts" | head -20` to see what your pattern actually catches before you trust it to build an index. A stray pattern can pull in vendor SDKs you never want to reference.
Keep automating!