dep-scan + atom currently treat Angular projects as generic JS/TS. In practice this produces a high false-negative rate for reachability: a large portion of application code looks unreachable because the real entry points and call chains live in framework constructs that the generic JS frontend can't follow.
The following are invisible in an Angular codebase today:
- Class members referenced only from HTML templates (
{{ }}, [prop], (event), *ngIf/*ngFor, and the @if/@for syntax in v17+)
- Constructor-injected services and the
inject() function
- Lazy-loaded routes via
loadChildren: () => import(...)
- Lifecycle hooks (
ngOnInit, ngOnDestroy, etc.) called by the framework rather than user code
- Decorator-driven entry points (
@Component, @Injectable, @HostListener, @ViewChild)
The result is that "non-reachable" classifications can't be trusted for Angular apps, which defeats the main reason to enable reachability.
Two questions before considering any contribution:
- Is framework-aware analysis in scope for atom, or is the design intentionally framework-agnostic and this kind of work expected to live elsewhere?
- If it is in scope, is there a preferred direction between a heuristic frontend (decorator-based entry points, template-string matching, route-string following; cheaper, roughly 80% of value, imprecise) and a semantic frontend (reuse
@angular/compiler to parse templates properly into the CPG; much more work, accurate, version-coupled to Angular)?
Want to understand direction before prototyping.
dep-scan + atom currently treat Angular projects as generic JS/TS. In practice this produces a high false-negative rate for reachability: a large portion of application code looks unreachable because the real entry points and call chains live in framework constructs that the generic JS frontend can't follow.
The following are invisible in an Angular codebase today:
{{ }},[prop],(event),*ngIf/*ngFor, and the@if/@forsyntax in v17+)inject()functionloadChildren: () => import(...)ngOnInit,ngOnDestroy, etc.) called by the framework rather than user code@Component,@Injectable,@HostListener,@ViewChild)The result is that "non-reachable" classifications can't be trusted for Angular apps, which defeats the main reason to enable reachability.
Two questions before considering any contribution:
@angular/compilerto parse templates properly into the CPG; much more work, accurate, version-coupled to Angular)?Want to understand direction before prototyping.