Tweak UMD / global semantics - #8678
Conversation
| "category": "Error", | ||
| "code": 2685 | ||
| }, | ||
| "Identifier '{0}' must be imported from a module": { |
There was a problem hiding this comment.
But that isn't specifically the solution. The problem is that you're using something intended to be used as a global. Importing an identifier by that name from a module might not work at all. Importing the module as that name would work.
A better message might be
The namespace '{0}' declared in '{1}' is not accessible within a module. Did you mean to import the file instead?
There was a problem hiding this comment.
We don't have a good way right now to generate {1} in that message (since we'd basically have to reverse-engineer a module name that would successfully resolve from the containing file).
How about
Global identifier {0} cannot be used from a module. Did you mean to import this from its module?
There was a problem hiding this comment.
What about getting the path relative to the project root?
Still confusing, but better. 😄 |
|
Any other comments? |
|
Fixes #7843 |
|
The message is a bit vague, and can be enhanced, other than that 👍 |
4 participants
The behavior for UMD declarations is now that you cannot use UMD symbols from external modules. This removes the confusing concept of "was this file referenced or not?".
I've also renamed
GlobalModuleExportDeclarationtoNamespaceExportDeclarationbecause it was confusing.Fixes #8255