Open anko opened 5 years ago
It's not a loop, it's a recursive fork. Using the --nodejs
option means that the test process spawns another node process with the same arguments... which means that the child process does what the parent was doing, namely, running all the tests, including the one which caused the fork...
Oh, I see!
There goes my plan though. :slightly_frowning_face: To make this test work as-is, the forked node process would need to call the provided log
and die
functions, for commandEq
to capture and check. I could do that by piping its stdio through something that calls log
/die
with converted buffers from its stdin
/stdout
, but that would destroy performance in non-test use.
I'd be more inclined to refactor test/cli.ls
into full end-to-end tests, running a child process lsc
for each and checking captured stdio.
It might be better to create a new file in test
for end-to-end tests, rather than refactor all of test/cli.ls
.
Trying to start on https://github.com/gkz/LiveScript/issues/880#issuecomment-471431184 by adding a failing test like a good developer, but adding this test—
—makes the tests loop forever:
What's happening?
I tried these things to troubleshoot:
git reset --hard ; npm i ; npm t
, then made the same change, but nope, still loops forever.command-eq
line incli.ls
. That works fine, so something about the line I'm adding specifically is making it choke.command.ls
tospawnSync
the node process instead ofspawn
. No difference, still loops forever.Any ideas?
Versions just in case: