My personal feeling is that the PR is correct as-is; a visitor can return a node of a type unrelated to the input type so long as it's then used properly. E.g. if a node has a prop of type Identifier, but accepts Expression, it should be fine to visit that and return a different expression and assign it, even when the input might be known to be Identifier explicitly.
It turns out that there is code which requires that the input not be related to the output (in the same manner I speculated about above), so, the code needs to stay as-is.
Decide whether or not visitor should still be optional.
Maybe deal with createJSDocDeprecatedTag.
Maybe deal with isParameter.
Decide if we are okay exporting BufferEncoding.
Decide VisitResult<Node | undefined> or VisitResult<Node> | undefined?
Maybe fix private handlers = new Map(...)
I investigated this; it turns out that a lot of our handlers don't actually match the type they're declared to return in the protocol! This turns into a much larger change so I think it's best to leave to another PR.
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.
TODO: