tape-run emitting an HTML file in root about tape-run HOT 9 CLOSED

if you reinstall browser-run, and so get the latest electron-stream as well, this shouldn't be an issue any more.

Tested with

$ ./node_modules/.bin/browserify test/fixtures/fail.js | ./bin/run.js

from tape-run.

@juliangruber thanks for the fast turn-around!

from tape-run.

i should have fixed this in electron-stream (a dependency), can you update your tape-run and tell me if this still happens?

from tape-run.

perfect, works great!

just curious, I see that it still makes the temporary file (and then immediately deletes it). did it always do that or did something change?

from tape-run.

@juliangruber also, it seems that the file doesn't get deleted if the tests fail

from tape-run.

just curious, I see that it still makes the temporary file (and then immediately deletes it). did it always do that or did something change?

You're right that this behavior is new. I needed to add those in order to add --node support for electron. Electron's cwd only seems to be set directly if you invoke it with $ electron script.js.

@juliangruber also, it seems that the file doesn't get deleted if the tests fail

Oh, I'll look into it.

from tape-run.

Hey there,

I've just installed a project of my own that was previously working with no problem running [email protected] only to now find that I can no longer successfully run tests with tape-run. I've since followed directions as outlined in numerous issue reports in regards to upgrading and cleaning node cache but with no success.

I have the same issue as raised by @davelandry where tape-run creates a file like .source.1491890007752.html which remains in the root if an error occurs. Sinon fake server and XHR Requests fail due to calling file:// protocol instead of http://localhost/.

This problem only occurs with electron, however I have to hack browser-run to use browser-launcher2 if I want to run tests in anything other than electron.

eg:

\node_modules\browser-run\lib\launch.js
- var launcher = require('browser-launcher');
+ var launcher = require('browser-launcher2');

TL;DR that's another nuisance issue I won't go into detail about here.

My Environment:
OS: Win32
Node: 6.10.2
npm: 3.10.10
Gulp: 3.9.1

[email protected]
[email protected]
[email protected]

Example of my test runner task:

gulp.task('js:test', ['js:lint'], () => {
  browserify('./src/tests.js')
    .transform('rollupify', {
      plugins: [nodeResolve, rollCommon]
    })
    .transform(babelify.configure({
      presets: ['es2015']
    }))
    .transform('envify', {
      PROJECT_VARIABLE: ''
    })
    .bundle()
    .on('error', function (err) {
      utility.errorHandler(err, this);
      this.emit('end');
    })
    .pipe(plumber({ errorHandler: utility.errorHandler }))
    .pipe(tapeRun())
    .pipe(tapSpec())
    .pipe(process.stdout);
});

Resulting Error:

Error: XMLHttpRequest failed; error code: Not Found
        at FakeXMLHttpRequest.xhr.onload (file:///<project root>.source.1491948906022.html:1569:18)
        at FakeXMLHttpRequest.<anonymous> (file:///<project root>.source.1491948906022.html:60132:26)
        at file:///<project root>.source.1491948906022.html:59670:26
        at Array.forEach (native)
        at FakeXMLHttpRequest.dispatchEvent (file:///<project root>.source.1491948906022.html:59668:19)
        at FakeXMLHttpRequest.readyStateChange (file:///<project root>.source.1491948906022.html:60455:18)
        at FakeXMLHttpRequest.setResponseBody (file:///<project root>.source.1491948906022.html:60622:14)
        at FakeXMLHttpRequest.respond (file:///<project root>.source.1491948906022.html:60628:14)
        at Object.processRequest (file:///<project root>.source.1491948906022.html:59921:25)
        at file:///<project root>.source.1491948906022.html:59897:18

References:
juliangruber/browser-run#135
juliangruber/electron-stream#22

This issue has stopped me dead in my tracks as rolling back seems to have no effect and I'm uncertain as to why, even starting from scratch with a purpose built test case and attempting to maintain the original [email protected] setup results in this failure now.

I should note also that the last working configuration was:
[email protected]
[email protected]
[email protected]

from tape-run.

I've finally rolled out a patch for electron-stream that makes it use the file:// protocol only for opts.node === true, otherwise it's back to good old http://.

Does this fix your problem?

For the .source* files, I know it's annoying, but maybe you can simply add them to your .gitignore for now?

from tape-run.

Legend,

this now works as expected (I assume you meant electron-stream? Which is now @5.0.3).

As for the .source. files, these are not really bothering me, I can ignore them and run a cleanup task as part of my workflow so no biggie.

Thanks for the quick response.

from tape-run.