Change import type determination to not use a RE on the symbol name#25381
Merged
weswigham merged 1 commit intoJul 3, 2018
Merged
Conversation
mhegazy
approved these changes
Jul 3, 2018
|
Damn you guys are awesome. Thanks! ❤️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #25278
So as it turns out, at using
getNameOfSymbolAsWritten, which itself defers todeclarationNameToString, which uses the verbatim original text of a module declaration's name and not the symbol's name (unless it has no node-based name) was an error. This meant ambient modules would be surrounded with single quotes if the original declaration used a single quoted string, rather than the double quotes we ensure we use internally (and therefore what we expect to match inambientModuleSymbolRegex).I've now changed
symbolToTypeNodeto use a much less brittle check forhasNonGlobalAugmentationExternalModuleSymbolon the symbol's declarations, and while I was at it, factored the module specifier parts out ofgetNameOfSymbolAsWritten(and reordered it so control flow worked better on it), since that's really not whatgetNameOfSymbolAsWrittenis for.