Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tape-run emitting an HTML file in root #58

Closed
davelandry opened this issue Mar 9, 2017 · 9 comments
Closed

tape-run emitting an HTML file in root #58

davelandry opened this issue Mar 9, 2017 · 9 comments

Comments

@davelandry
Copy link

Thanks for such a great package! Just upgraded to v3, and whenever I run my tests it produces a file in my root directory that looks like this:

.source.1489078148412.html

Which contains the compiled code with the HTML wrap. Here is the command that I'm running:

browserify -t [ babelify --presets [ es2015 ] ] test/*.js | tape-run

Tests run/exit correctly, but is there any way to not create this file? For now I can just remove them manually (new one is created with the current Date timestamp on each run).

@juliangruber
Copy link
Collaborator

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

@davelandry
Copy link
Author

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?

@davelandry
Copy link
Author

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

@juliangruber
Copy link
Collaborator

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.

@juliangruber juliangruber reopened this Mar 13, 2017
@juliangruber
Copy link
Collaborator

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

@davelandry
Copy link
Author

@juliangruber thanks for the fast turn-around!

@nedkelly
Copy link

nedkelly commented Apr 12, 2017

Hey there,

I've just installed a project of my own that was previously working with no problem running tape-run@2.1.4 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

tape-run@3.0.0
browser-run@4.0.2
electron-stream@5.0.2

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 tape-run@2.1.4 setup results in this failure now.

I should note also that the last working configuration was:
tape-run@2.1.4
browser-run@3.2.0
electron-stream@3.0.2

@juliangruber
Copy link
Collaborator

juliangruber commented Apr 12, 2017

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?

@nedkelly
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants