Missing standalone components declared with button[custom-button] are not reported by the compiler
#46351
Comments
|
Yes, this is the "blind spot" in our template syntax. Essentially we can't know, from the syntax, if
There is a longer discussion on the topic in #3425 |
|
@pkozlowski-opensource Thanks for clarification. I am observing similar behaviour with sugar-style directives (*ngIf for example), is it the same reason? Example - https://stackblitz.com/edit/angular-standalone-4tmeb9?file=src%2Fmain.ts,src%2Fapp%2Fimage.component.ts EDIT: |
|
Yes, directives matching on even handlers (ex. The |
|
If it's not possible for compiler, maybe it make sense to pass this to developer? preudo code from future .angularlint |
|
#46146 will be in 14.1 which adds this warning for |
|
I was asked to copy and paste here the description of a duplicate issue I opened (#46661), so here it goes: If a directive has an attribute selector and the attribute is used without square brackets, such as When using NgModules, such a bug happens rarely, because you rarely forget to import the router module (for example) in your main or feature module. But when using standalone components, it's much more frequent, because the import needs to be repeated on every component that needs the directive, and of course we tend to only import what's absolutely needed. After migrating two relatively small applications to standalone components, I've introduced such a bug, especially with routerLink, at least twice. I understand why the compiler doesn't complain, but this, IMHO, is a source of hard to detect bugs: I doubt most people have integration tests checking that each and every link in their components works as expected. And even at runtime, the bug goes unnoticed until you click on the link and realize it doesn't work. It would be nice to be able to activate some compiler option that would, for example, check that any non-standard HTML attribute used in a component (such as routerLink) matches with a known directive selector for that component. Or to be able to provide a list of selectors or attributes that must be checked. |
|
+💯 huge bug source... I'd love to see a strict build option that complains about any "unknown attribute". This way we are sure that imports are not missing. Rather than maintaining a list of all known html attributes (if that is the main concern/difficulty)... at least give us a "allowedAttributes: []" where we can specify which attributes are safe to ignore (do not require an import). |
To me this a pretty big design flaw 🤔 |
|
I don't know if this is the same - I think might be another use case. We have lots of custom form control components to use inside mat-form-field. The compiler also doesn't detect these as being missed if they are in the template but not imported in the standalone component. Should I raise a new issue for this or is the underlying problem the same? Here app-rich-text-form-control isn't imported but the compiler doesn't pick it up. Fails at runtime |
|
+1 for major pain point with standalone components |
|
Just wanted to mention for everyone here, Webstorm (specifically the EAP version is what I tried) DOES pick up these warnings in the editor. Might save you a headache or two after you convert everything to standalone to load up the 30 day Webstorm trial and comb through your HTML files 
|
|
I am also feeling sad when migrated but missing the tool support. thanks @kyjus25 for alternatives. |
|
My suggestion would be to solve this with a new extended diagnosis. The new diagnosis would warns for unknown tags and unknown attributes. Each project can gradually configure the diagnosis with a list of allowed unknown tags and allowed unknown attributes. In addition users can opt-in for this rule to break the build by configuring the diagnostic as an error, to be really strict. Of course this is not an ideal solution, but it should be relatively simple to implement. And it would be better than runtime errors, and so much better than runtime lack of functionality (as seen with |
|
@eneajaho Sorry to bother. I pulled your https://github.com/eneajaho/angular/tree/feat/potential-directives-in-templates branch down and fumbled my way thru getting the proper test to run, but the directives array came up empty. Was this your conclusion as well or did I do something wrong? I was going to see if I could assist but from what I saw you had configured the test right but the function didn't seem to work. |
I came to same conclusion, but I need to check more on that. |
|
Guys, this ticket seems to be very specific about some selectors but personally I have the same issue with any component. In a standalone component's template, if I forget to add an import, there is no compile time error but it breaks at runtime. I don't find an issue in this repo for that. Am I the only one having this problem for all components (not ones with special selectors)? |
|
This seems like an issue beyond directives. If a component hosts a directive, it does not give compilation errors: <!-- Compilation error. -->
<app-component-that-does-not-exist></app-component-that-does-not-exist>
<!-- Runtime error. -->
<app-component-that-does-not-exist
[formControl]="formControl"
></app-component-that-does-not-exist>#51064 should probably be re-opened. |
|
@thePunderWoman this is an incredibly urgent problem. I don't get it, the angular team wants everyone to migrate to standalone architecture... yet we should expect that directives of existing libraries should just silently fail like this? On making new components, using the directive We don't use eslint because of how slow it is (we use biome instead) so can't benefit from any 3rd party provided checks here. angular/vscode-ng-language-service#1859 (comment) seems this problem was picked up at least 18 months ago... nothing was done about it. @AlbertoMontalesi we have to just be extremely careful when authoring new components or adding directives to existing ones. I have no idea how we can thoroughly catch errors though. mentioned @devversion from vscode angular extension team to call attention to this |
|
@jpike88 The team is very aware of this issue. The main problem behind this feature are the false-positives. There are no difference between a random attribute and a directive selector. |
|
Seems to me that could be a feature not a bug at least in its initial implementation. Using non-directive attributes is something we don't do as a rule. |
|
What about an opt in flag to enable it. |
|
So far it seems the current approach to the fix is to suggest changing the authoring format so that it is no longer a blind spot
|
There could be something in this I reckon, maybe a whitelist (inc regex) of general attributes in angular.json, then everything else gets validated. That way you can customise to what you need. |
@JeanMeche Can you follow up on this comment? In what scenarios is it good/acceptable practice to be peppering elements with attributes that aren't HTML DOM or directives? I can only think of perhaps Why can't a whitelist/regex override be provided instead as suggested? |
|
One year ago I suggested to use extended diagnostic to solve this in a "best-effort" kind of way. While it requires some manual configuration, it would at least offers us a relatively high confidence that components/directives code is actually executed. But I don't think the core team gave any feedback about that... So I'm joining @jpike88 in asking a slightly more elaborated feedback from the core team. Are you actually working on something ? roughly when could we expect a possible solution, 2025 ? is "best-effort" not acceptable ? should the community create a PR ? or solve this outside of the core project ? @eneajaho your experimental branch seems to be inactive for the past few weeks. Do you still plan to work on that ? |
With my relatively superficial understanding of all that goes into this I can see how false-positives might be a big issue, but I agree with the comments there would still be value in still exposing this information to developers (as suggested behind a flag and / or purely as informational). The current state of missing imports just causing things just break (often silently) is indeed an easy-to-miss source of bugs, as noted above. A random thought I have (always dangerous saying those in public): if you have a component Thanks to the team for all their work. |
|
We just got bitten by that again. After (manually) migrating select components to standalone, we missed the MatButton import. As a result ends up unstyled. |
|
Has anyone suggested flipping this on it's head?
Logic: If you are using a directive/component for the first time you likely won't forget to add it to imports.. if you are using it in New code or refactoring you are likely to miss it, but it's in your project elsewhere and should be easir to detect from a selector first perspective |
|
Interesting take. Once you have a list of directives you could use a Bloom Filter to check all properties quickly and efficiently In the case of a Bloom Filter, you would know very quickly if a property is not a directive 🤓 |
|
Note to future readers: make sure to enable strictTemplates This issue is a specific case where strictTemplates doesn't discover custom directives when they are used in a template without property data binding. (I was searching for an option like this stackblitz with angular 19 Confirms custom directive selectors are still not picked up by The only way it notices that a property |
|
@jamie-pate I've said it previously in the thread, but after you convert to standalone I recommend downloading the Webstorm trial (or free if using for personal use) which does catch unimported custom directives. VS Code is the only one it seems that doesn't. Worth the peace of mind |
Which @angular/* package(s) are the source of the bug?
core
Is this a regression?
No
Description
When standalone component is created with
@Component({ selector: 'button[cv-button]'it will be not reported during compile timePlease provide a link to a minimal reproduction of the bug
https://stackblitz.com/edit/angular-standalone-uzrsmn?file=src%2Fmain.ts
Please provide the exception or error you saw
Please provide the environment you discovered this bug in (run
ng version)Anything else?
No response
The text was updated successfully, but these errors were encountered: