Manipulating nodes within forEachChild or forEachDescendant causes out of date nodes to be wrapped

[dsherret]

Obvious why this is happening, just have to find a solution:

const project = new Project({ useVirtualFileSystem: true });
const sourceFile = project.createSourceFile("test.ts", `
const t = 5;

function test() {};`);

sourceFile.forEachDescendant(node => {
    if (TypeGuards.isVariableDeclaration(node))
        node.setType("any");
    console.log("Kind: " + node.getKindName());
    console.log("Text: " + node.getFullText());
});

Outputs:

Kind: VariableStatement
Text:
const t = 5;
Kind: VariableDeclarationList
Text:
const t = 5
Kind: VariableDeclaration
Text:  t: any = 5
Kind: Identifier
Text:  t
Kind: AnyKeyword
Text:  any
Kind: NumericLiteral
Text:  5
Kind: FunctionDeclaration
Text:  = 5;

function test
Kind: Identifier
Text: ction
Kind: Block
Text: est
Kind: EmptyStatement
Text: (
Kind: EndOfFileToken
Text:

[cancerberoSgx]

Interesting couple of questions / thoughts:

do you think this is an issue that the library should tackle or should the user be responsible of first query all the nodes he wants to modify and modify them all together as suggested in the docs ? Thinking very roughly I don't see way of solving the problem besides visiting all source file's nodes and fix their ranges which could be very expensive. Will check it out how / if is solved for other modifications like addClass/addMethod, etc I think in those there is no such problem . I would like to know what's your plan for this if you have one and is short to explain :)

What about making the whole sourcefile (forgotten) when user modify any of its nodes as it happens with insertText() ?

Also, perhaps it could related with #351 - if I have a way to identify nodes uniquely then something like the following should be safe: ids.forEach(id=>sourceFile.query(id).modify()) -

(sorry for thinking aloud here)

[dsherret]

The node tracking between manipulations is one of the main features of this library and what makes it so easy to use.

For performance reasons, it's for this specific situation:

If the code analysis is using types, symbols type checker, or program, then a large performance improvement can be gained by doing an initial analysis of the code first, then afterwards carrying out the manipulations.

Anyway, this is a really easy fix. Will do it soon.