Yesterday at its Build conference, Microsoft released the Visual Studio Code editor which is a lightweight, cross-platform tool for building web and cloud applications.
I've been using internal releases for a while and highly recommend trying it out!

One thing I didn't know about until yesterday was support for Tasks to automate common steps like build and testing.
As the documentation shows, there's already knowledge of common build frameworks, including gulp for Node.js and io.js.
But for simple Node projects I like to automate via npm's scripts because they're simple and make it easy to integrate with CI systems like Travis.
So I whipped up a simple tasks.json for Code that handles build, test, and lint for typical npm configurations.
I've included it below for anyone who's interested.

Note: Thanks to metadata, the build and test tasks are recognized as such by Code and easily run with the default hotkeys Ctrl+Shift+B and Ctrl+Shift+T.

Tree nodes are assumed to have a numeric value and references to their left and right nodes (both possibly null).

I used the name value (vs. data) because it is slightly more specific.

I decided on an iterative algorithm because it has two notable advantages over recursion:

In the worst case for a tree with N nodes, an iterative solution has bookkeeping for N/2 nodes (when starting to process the leaf nodes of a balanced tree assuming nodes were queued) whereas a recursive solution has bookkeeping for all N nodes (when processing the deepest node of a completely unbalanced tree).

Because there are two recursive calls, I don't thinktail recursion can be counted on to fix the worst-case behavior.

The memory used for bookkeeping by an iterative solution comes from the heap which is generally much larger than the thread stack.

To be fair, neither advantage is likely to be significant in practice - but they make good discussion points during an interview. :)

The iterative algorithm has a disadvantage:

Bookkeeping requires an additional object type (wrapper in the code above) which associates the relevant min and max bounds with pending node instances.

... unless you avoid the wrapper by augmenting the node elements themselves.

... which is quite easy in JavaScript thanks to its dynamic type system.

The code uses a stack (vs. a queue) because stacks tend to be simpler than queues - especially when implemented with an array.

I made use of the fact that comparing a number to undefined evaluates to false so I could avoid specifying explicit minimum/maximum values (as in the Wikipedia example) or making HasValue checks (as in James's example).

If you have a different approach or a suggestion to simplify this one, please share!