<kentonv>
omgwtf, meteor tool won't run because some dependency npm module includes a test file called "package.json" which is intentionally malformed (it's for some sort of parser test), and meteor seems to be trying to parse every package.json under node_modules
<TimMc>
That would be a reasonable hotfix but not a reasonable "done, issue closed".
<isd>
I wish we had the resources to port away from meteor.
<digitalcircuit>
TimMc: Oof. "// This is going to break the run but at least with a clear error indicating what is the problematic package.json"
<isd>
I wonder if this is related to why our meteor build step gets oom killed in a VM with <= 3GiB of memory.
<kentonv>
good news: reverting the 'resolve' module works around the problem. Bad news: 22 test failures when I got only 2 before updating any dependencies. But I think the dependencies didn't break anything, each test run seems to randomly have 2, 3, or 22 test failures
<kentonv>
javascript error: window.loginDevAccountFast is not a function
<kentonv>
yeah after reverting to exactly what I ran yesterday it still has 22 failures when yesterday it had 2. sigh.
<isd>
I feel like I've seen that one before and fixed it with a make clean and a fresh build
<kentonv>
this was a fresh build though. But I'm trying it again.
<isd>
I think at some point I got a build where it had minified a way that variable name.
<isd>
*away
<isd>
...so when the test tried to call it it was not found.
<isd>
I don't know what triggers the busted build though.
<isd>
grepping the output for miniposix::write would be the way to confirm it.
<isd>
I am at the moment building a custom kernel with some debug prints in it to try to figure out why that's returning EPERM. It happens consistently for me in test, never in prod.
<kentonv>
I think 22 is just *all* of the tests
<kentonv>
I don't think it's related to that issue... the tests all fail with the window.loginDevAccountFast error
<kentonv>
anyway the release was dependency-updates-only so... I went ahead and pushed it. It does seem to work fine on alpha.
<isd>
Ok, yeah, you're right that is just all the tests.
<isd>
...once we actually get all the tests passing again (which I'm trying to seriously push on now), I would like to from there take test failures as blocking, even if they seem spurrious -- not having them available is paralyzing when trying to actually hack on Sandstorm, and so I've got a few things on hold until I can fix these...
<kentonv>
well, that works up until the point where I need to do the monthly release but I don't have time to debug the spurious test failures... :/