🤖 User test baselines have changed #28524
Conversation
| @@ -0,0 +1,8 @@ | |||
| Exit Code: 1 | |||
| Standard output: | |||
| src/App.tsx(2,8): error TS2307: Cannot find module './App.css'. | |||
There was a problem hiding this comment.
!?!? Did something in this project's dependency hierarchy change to no longer include a css blanket module declaration? cc @DanielRosenwasser
There was a problem hiding this comment.
Ahhhhhhhhhhhhhhhhhhhhhhh, I know what it is - we don't have a *.css module reference in the starter and never have. And for some reason, we've never validated the paths on ImportDeclarations with no clauses (because we only do that during export resolution and if you request no members, we do no export resolution). In 7a71887, getAlternativeContainingModules attempts a lookup of all imports in a file (including ones we don't look at exports for) to try to find aliases of a symbol for printing a better name for it. This causes us to actually check the validity of the import and learn that in fact it is not valid.
There was a problem hiding this comment.
@DanielRosenwasser didn't that we don't check these kinds of imports come up recently? Do we want to formally fix the behavior and check their validity (like this, but ideally more explicitly), or should I suppress any errors from resolveExternalModuleName during getAlternativeContainingModules?
Please review the diff and merge if no changes are unexpected.
You can view the build log here.
cc @weswigham @sandersn @RyanCavanaugh