New replaced node should be traversed

[fabiomcosta]

This is first of all a question, shouldn't the new nodes added by replace be traversed?

Ex:

types.traverse(ast, function() {
  if ( ... ) {
    this.replace(functionExpressionNode);
  }
});

functionExpressionNode doesn't get traversed.

[benjamn]

Yeah, this story is pretty broken. I originally didn't want to force replacement nodes to be traversed, but that seems to be what one almost always wants.

You can technically call

types.traverse(
  this.replace(functionExpressionNode)[0],
  arguments.callee
);

but that's admittedly pretty ugly.

[benjamn]

One case where you don't want automatic traversal is when you pass multiple arguments to this.replace and one of the arguments is the current node:

types.traverse(ast, function addLogging(node) {
  if (n.Statement.check(node)) {
    this.replace(
      makeConsoleLogStatementFor(node),
      node // Don't want to traverse this node again!
    );
  }
});

Without some sort of additional check, automatic traversal would result in this traversal never terminating.

[fabiomcosta]

It seems like having both methods would be the best then.
Add replaceAndTraverse() and keep replace()?

[fabiomcosta]

Hi @benjamn just to let you know

types.traverse(
  this.replace(functionExpressionNode)[0],
  arguments.callee
);

Worked well for me, thank you! :)

I was doing:

this.replace(functionExpressionNode);
types.traverse(
  functionExpressionNode,
  arguments.callee
);

Which was making me lose all the parent context of functionExpressionNode.

[benjamn]

Fixed by c6fa69d and 92a64f9. You should no longer have to explicitly traverse the new path objects returned from path.replace.

[fabiomcosta]

👍

On Tuesday, July 8, 2014, Ben Newman notifications@github.com wrote:

Closed #25 #25.

—
Reply to this email directly or view it on GitHub
#25 (comment).

Fabio Miranda Costa
twitter: @fabioMiranda
github: fabiomcosta