ava doesn't support a "no transpilation" option. a no transpile option would improve performance and, more importantly, yield a stable, easy debugging experience for those of us who don't need/want transpilation. i use ava for many of it's great features, transpilation not being one of them. transpilation+source_maps+editors frequently don't play nicely.
observe:

^^ _shows setting breakpoints, running ava, transpiliation happens behind the scenes, and my editor losing it's cool as it lost refs to the actual lines breakpoints were originally on, pretest_
this is already a known issue without a solution--it even says so in the docs. these issues "just go away" when i can use raw node, and the runtime runs just my code, untouched!
thanks for the consideration! great work.
Yeah, I'd like to see that too. Now that Node.js 8 has native async/await, there's no longer a need for me personally to transpile. The main reason we chose to do transpilation by default initially was to get async/await.
@avajs/core Thoughts?
Yes. See also https://github.com/avajs/ava/issues/709 (don't worry I'll clean up the issues).
Say we have a "babel': false option. Should that also imply "powerAssert": false? I'm leaning towards yes, since power-assert requires transpilation, whether via Babel or https://github.com/power-assert-js/espower-loader. But it might be an unexpected way to lose that feature. Same goes for our throws helper. Should there be an easy way to opt back in to it?
Say we have a "babel': false option. Should that also imply "powerAssert": false?
Yes, unless we can figure out a way to run it efficiently at runtime on a failure.
Should there be an easy way to opt back in to it?
I don't see how you could opt into the throws helper again without having Babel, and then using babel: false is moot.
There's something to be said for separating AVA's file manipulations from syntax transforms. The babel option could refer to syntax transforms only, while we have a separate transpileEnhancements option. This would supersede the current powerAssert option.
Since we're still looking to integrate source transpilation and also support TypeScript, it makes sense (at least to me) that the enhancements are controlled separately.
I would use this a lot and it would have helped me today. 馃槂
At the moment, transpiling is breaking valid code that runs on LTS versions of Node.
See: https://github.com/avajs/ava/commit/37c9122c50722b06039f1cc2306a7c176fd3c786#commitcomment-25662855
compileEnhancements option. If set to false, and babel is also set to false, then the Babel pipeline is skipped in its entirety.@novemberborn, you're an 馃懠 . can't wait to test this out!
Hmm...
yarn (observed the request hit GH, though the gif below is too fast moving :))// package.json
"ava": {
"options": {
"compileEnhancements": false
}
}
sure enough, breakpoints still jump around, leading me to think something is still being transpiled (or built, run, and sourcemapped at least)

@cdaringe that's not how AVA's options are set. You'll also still need to disable the regular Babel compilation that AVA applies:
"ava": {
"babel": false,
"compileEnhancements": false
}
What would this do?
"ava": {
"babel": false,
"compileEnhancements": true
}
Would the false be ignored? I'm wondering if it should imply "compileEnhancements" : false.
@sholladay AVA won't apply the stage-4 preset, but power-assert will keep working, and we'd detect t.throws(throw new Error()).
Whilst those last two features are currently provided through a Babel preset I think that's an implementation detail. We could change the compiler we use, and when we add native support for TypeScript we may still want to add those features to test files written in TypeScript.
hey @novemberborn, whoops, sorry for that!
even with
"ava": {
"babel": false,
"compileEnhancements": false
}
i'm still seeing the jumpiness. is the file still being meddled with or source mapped somehow?
@cdaringe are you per chance applying nyc in your test run? Feel free to pop in on https://gitter.im/avajs/ava so we can hash this out more directly (assuming our time zones have some overlap).
hi @novemberborn, thx for the continued support. indeed, i was using nyc. after removing nyc, however, the issue persists. sorry i was late to see this message. im out for a few days for surgery but will be back soon. i'll try and reach out to you on gitter then.
OR, here's a teeny tiny reproduction: https://github.com/cdaringe/vscode-ava-no-transpile-party-time
it's wired up per instruction. clone, npm i/yarn, then readme steps!
@cdaringe aha! profile.js doesn't skip compilation. It's a bit of an odd duck. Nice catch!
Is this issue with vscode really a vscode issue? When I add a breakpoint in a jest file with es modules and inside an async function it works fine! Do we provide sourcemaps in ava?
Most helpful comment
@sholladay AVA won't apply the
stage-4preset, but power-assert will keep working, and we'd detectt.throws(throw new Error()).Whilst those last two features are currently provided through a Babel preset I think that's an implementation detail. We could change the compiler we use, and when we add native support for TypeScript we may still want to add those features to test files written in TypeScript.