Add additional diagnostic for packages that only resolve under non-exports-respecting modes#52173
Conversation
…ports-respecting modes
| "category": "Message", | ||
| "code": 6276 | ||
| }, | ||
| "Resolution of non-relative name failed; trying with modern Node resolution features disabled to see if npm library needs configuration update.": { |
There was a problem hiding this comment.
a non-relative name is one like "foo", not "./foo.js", right?
I guess this is output for traceResolution, so it's probably OK to be technical, but is 'non-relative' the friendliest term we have? I have to think about it a bit every time I see the term. Could be that I was ruined by reading an old, old "how Typescript implements Node resolution" document, though.
There was a problem hiding this comment.
I've also found myself wondering if there's a good term for imports that are neither absolute nor relative to the containing file, but rather relative to some configured root or resolved via aliasing. Floating? Inferred? I guess "absolute" could be reused since giving full filesystem paths for imports should be vanishingly rare, but it doesn't feel accurate either.
sandersn
left a comment
There was a problem hiding this comment.
I like the new error a lot better. I had a couple of bike-shed comments but no suggestions that I am confident in.
src/compiler/diagnosticMessages.json
Outdated
| "category": "Message", | ||
| "code": 6277 | ||
| }, | ||
| "There are types at '{0}', but this result could not be resolved when respecting package.json \"exports\". The '{1}' library may need to update its package.json.": { |
There was a problem hiding this comment.
Q: Would a similar error for "imports" for resolving #-prefixed nonrelative names be useful?
Adds a message to most of the implicit any errors in #51973 (you can’t see the chained details on the bot’s GitHub comment, unfortunately)