$ ava --report
**ava:** 0.14
**node:** 4.4.0,
**npm:** 3.x.x
**os:** darwin 14.5.0
The above is already copied to your clipboard. Paste it in your GitHub issue report.
I like the idea, but I think it be better if ava --report opened the new issue page with the issue body prefilled with that info?
Example: https://github.com/sindresorhus/caprine/blob/2acdd358eafdc42b45b532c90e87ba5465a30de7/menu.js#L53-L62
Yeah sure.
We could even force them to specify a single test file:
ava --report test.js
Then grab the source for the failing test and include it as well as the stack trace
Then grab the source for the failing test and include it as well as the stack trace
In that case tests could take up a lot of space in an issue. I suggest creating an anonymous gist with the contents of a test file. Authorization (api key) is not required for it.
In that case tests could take up a lot of space in an issue. I suggest creating an anonymous gist with the contents of a test file. Authorization (api key) is not required for it.
Yeah, I was worried about the size of the test file being included as well. My thought was we could use some babel tricks to pick a single test function out of the larger test file. (maybe grab beforeEach methods too? That could still get pretty verbose.
My main concern with automatically posting a gist is that we have no way of knowing if it contains sensitive information (security keys etc). I like the idea, but the security hole is a pretty huge downside IMO. We could give them a big old warning prompt I guess.
Can I post
test/foo.jsto an anonymous gist on Github? You should say NO iftest/foo.jscontains any sensitive information like private keys/ etc.
I think the prompt is a better solution. Babel trickery will bring complexity and more bugs, as a result.
I think the prompt is a better solution. Babel trickery will bring complexity and more bugs, as a result.
Where did it go? Did you change your mind? I think it's a fair point. We may be implementing some of that Babel trickery anyways.
Between the Babel helpers and Eslint stuff, we're getting pretty good at static analysis. We would definitely provide fallbacks. I think long term, getting good bug reports is going to save us a lot of maintenance time and overhead - so it is worth some investment. I know I waste a good amount of time chasing down bug reports that would have gotten solved a lot quicker with the right info.
Where did it go? Did you change your mind? I think it's a fair point.
Did not understand what you mean by that.
We may be implementing some of that Babel trickery anyways.
We may, but we'd rather spend efforts on AVA itself now, as there are lots of issues on the table.
I agree with James long-term, but right now I think we should go with the easy solution.
Did not understand what you mean by that.
I had a notification and email with your message, but it wasn't showing up on the page. Thought you deleted it. I think GH was having issues. I had commits taking a long time to appear, etc
Is this meant to be used for reporting AVA bugs? It's interesting but it doesn't seem terribly important. We've been doing OK without so I'm closing this.