Improve error message `Cannot resolve type entity ${entity} to {symbol|declaration}`

[mwaibel-go]

Command

build

Description

I’m talking about this error, for instance, which people seem to encounter somewhat often [1–5]:

$ ng build
⠋ Generating browser application bundles (phase: building)...
✔ Browser application bundle generation complete.

./src/main.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Cannot resolve type entity i7.BusifiableButtonComponent to symbol

This error message is not very actionable.

[1] https://stackoverflow.com/questions/71675705/error-cannot-resolve-type-entity-i10-bidimodule-to-symbol-while-building-angula
[2] primefaces/primeng#11581
[3] valor-software/ngx-bootstrap#6662
[4] #46441
[5] https://onthecode.co.uk/blog/error-cannot-resolve-type-entity-i3-dialogmodule-to-symbol

Describe the solution you'd like

The issue seems to always be related to a transitive dependency not being found. If that is the true meaning of the error, I suggest rewording the error message to reflect that. I don’t know how much information is available at this point. My dreamed-of error message would be something like this (drawing inspiration from JoostK’s comment):

The type ${entity} could not be found. It seems to be a transitive dependency via this import chain:
(root project) → (dependency) → (dependency) → ${entity}.
This typically happens when a library is linked from another directory tree, where the necessary dependencies are not in a location the compiler can find, for instance when there is no corresponding node_modules directory from within that tree.
Make sure that the library’s properly declares its dependencies and that they are installed.
If it is due to symbolic links, then setting projects.${project}.architect.build.options.preserveSymlinks: true in the angular.json file may help. Otherwise, explicit path mappings for the unresolved dependency may also help.

At the very least, the file that imports the unresolvable entity should be displayed, again as suggested by JoostK.

Describe alternatives you've considered

No response

[JoostK]

What version is this using? There have been changes in this area to be more resilient towards failure modes.

[mwaibel-go]

Sorry, I’m lacking the language skill to understand the phrase “resilient towards failure modes.” Updating Angular didn’t make the compiler withstand this error variety (how could it?).

But you’re right, the error message changed in v19. It is now

./node_modules/${library}.mjs:13:0-47 - Error: Module not found: Error: Can't resolve '${dependency}' in '${import location}/fesm2022'

which is much clearer and gives the offending file.

I still think pointing users toward possible error causes might be an improvement, but IMHO changing the message further isn’t as pressing as it was prior to v19. Thank you for having a look!

[JoostK]

Sorry, I’m lacking the language skill to understand the phrase “resilient towards failure modes.” Updating Angular didn’t make the compiler withstand this error variety (how could it?).

Sorry this was a bit cryptic. By "failures modes" I mean the possibilities for code to fail, and resilience was referring to how a diagnostic should be reported instead of crashing the compiler. So not really resilient, indeed, I should have used a different word.

There's various ways this error can occur:

1. a peerDependency of a library has not been installed into the workspace.
2. A symlink is used without preserveSymlinks: true and the dependency is only installed in the originating workspace, not in the symlink target's directory hierarchy. The opposite can also happen with preserveSymlinks: false.