Hi everyone. I've been evaluating Codeium for our team's Angular monorepo, and overall, I'm impressed with its code completion and chat features. It's great for standard Angular constructs like `*ngIf` or `ngModel`. However, we've built a substantial library of custom directives over the years—things like `*appDataGridRow`, `*appPermission`, or `appHighlight`—and this is where I'm hitting a wall.
The assistant seems to have no awareness of these custom directives. When I'm in a template and start typing `*app`, I get no relevant completions. More critically, if I ask it to "add a permission guard to this button using our `*appPermission` directive," it either hallucinates a non-existent API or suggests a generic `*ngIf` with a manual service call, which misses the point entirely. It's clear the model isn't indexing or understanding our project-specific directive definitions.
I've tried a few approaches without much success:
* **Project Indexing:** I've ensured the entire workspace is indexed (no errors in the Codeium dashboard). It seems to index `.ts` files well for autocompletion, but the connection to how these directives are *used* in templates isn't being made.
* **Providing Context via Chat:** I've pasted the directive's actual source code (the `@Directive` decorator with its selector and inputs) into a chat session and *then* asked for help. This works for that immediate chat, but the knowledge doesn't persist or transfer to the autocompletion engine.
* **Configuration:** I've scoured the settings for any path to provide a custom "schema" or directive list, similar to how you might configure the Angular Language Service, but found nothing.
My current theory is that the underlying model, while trained on vast amounts of public code, has no way to dynamically learn the selectors, inputs, and outputs of *our* private directives. The indexing might be more for finding and referencing code snippets, not for augmenting the model's intrinsic understanding of Angular's template syntax.
**My question to the community:** Has anyone successfully bridged this gap? I'm looking for a workflow or configuration that might help.
Some specific angles I'm considering:
* Is there a way to generate a type definition file or a custom "hints" file for our directives that I can place in the project for Codeium to pick up?
* Could writing extensive JSDoc comments on the directive classes themselves, in a specific format, improve the model's understanding?
* Or is this simply a current limitation where we have to rely more on the chat (with manual context provision) for custom directive work and accept that autocomplete will be basic?
Any insights, especially from others working with extensive custom Angular component libraries, would be immensely helpful. The productivity boost on standard code is significant, and I'd love to extend that to our bespoke abstractions.
—Chris
Prod is the only environment that matters.
I've run into a similar issue with custom infrastructure in other contexts. The core problem is likely that the indexing, while thorough for explicit code, isn't building a semantic model of your application's *interface* - the directives' public selectors and their expected inputs/outputs. It sees the class definitions but doesn't infer their template usage contracts.
You might need a more explicit bridge. Have you tried creating a small, well-commented TypeScript file that acts as a manifest, re-exporting and documenting the directive selectors and their purposes? For example:
```typescript
// `codeium-directives.manifest.ts`
/**
* Core custom directive library for Angular application templates.
* @manifest
*/
// Structural Directives
export { AppDataGridRowDirective as *appDataGridRow } from '@shared/directives/data-grid.directive';
export { AppPermissionDirective as *appPermission } from '@security/directives/permission.directive';
// Attribute Directives
export { HighlightDirective as appHighlight } from '@shared/directives/visual.directive';
```
Indexing might pick up on these documented exports as a stronger signal. Place this file in a root directory and see if chat references improve after a re-index. It's a workaround, but it forces a centralized definition the model can latch onto.
Your data is only as good as your pipeline.