Ava: Allow tests files to have any extension (i.e. `.jsx`, `.ts`)

[dustinsanders]

With the latest release(0.13) and the ability to support jsx; I would like the ability to write my test that contains jsx with a jsx extension. However ava is filtering only for files with .js extensions. I'm a little confused as to why ava allows for a glob pattern in the cli but then only filters down to .js files.

I can make a PR if this is something worthwhile to the maintainers.

---

See conclusion here: https://github.com/avajs/ava/issues/631#issuecomment-248659780

[sotojuan]

Personally I'd argue that there's no point in using .jsx files in general, but that's for another debate. This would only require changing one line, so I am for it.

[jamestalmage]

Extensions provide hints to the IDE as to which language features should be enabled.

My question is, do we just make a special exception for .jsx, or parse glob strings for extensions?

ava test/*.{js,jsx}

Would enable js and jsx

[dustinsanders]

I think ideally ava would accept any extension, as long as there is a register hook to get the file to vanilla javascript. I believe this would also fix issue #521.

[jamestalmage]

I think ideally ava would accept any extension, as long as there is a register hook to get the file to vanilla javascript.

I like that thinking. The only difficulty is that we can't know the list of registered extensions in the parent process, we process require hooks in the child.

[novemberborn]

I think we can support .jsx specifically. We could even add the Babel transform for .jsx files (though perhaps not depend on it).

Accepting any extension is trickier. We might have to swap out the compiler. #577 discusses this with regards to source files but the same would apply here. I suspect we might solve that with an explicit extension registry, not just accepting whatever is matched by the glob patterns.

[jamestalmage]

Why is matching the glob string problematic? If they explicitly define an extension just trust the user will add the require hook themselves (perhaps a helpful message if they don't).

[sindresorhus]

If they explicitly define an extension just trust the user will add the require hook themselves (perhaps a helpful message if they don't).

:+1:

[novemberborn]

If they explicitly define an extension just trust the user will add the require hook themselves

Yes, but this is the part we're currently missing. You can't swap out the Babel precompiler. Adding .jsx support is easier because it uses Babel.

[vadimdemedes]

So, we agreed to accept .jsx extensions in our API?

[jamestalmage]

Yes, but this is the part we're currently missing. You can't swap out the Babel precompiler.

You can by combining babel:false and require: 'some-precompiler'. Let's take coffee-script support for example. A complete config should look like this:

{
  "ava": {
    "require": "coffee-script/register",
    "babel": false,
    "files":  "test/**/*.coffee"
  }
}

JSX should be like this:

{
  "ava": {
    "babel": "inherit" // with .jsx support setup correction in .babelrc,
    "files": "test/**/*.{js,jsx}"
  }
}

So, we agreed to accept .jsx extensions in our API?

I would just as soon not hard code non-standard extensions into AVA if we can avoid it (which I think we can fairly easily in this case).

[novemberborn]

I would just as soon not hard code non-standard extensions into AVA if we can avoid it (which I think we can fairly easily in this case).

We are currently hard coding for .js so that would have to change.

[sindresorhus]

We are currently hard coding for .js so that would have to change.

That's because we want $ ava some-directory to just work, without having to specify it like some-directory/**/*.{js,jsx}. We could still support both though, just that if you want other extensions that .js you need an explicit glob.

[novemberborn]

@sindresorhus so remove code that restricts test files to .js extensions, but leave glob patterns as is? Presumably we're requiring .js extensions in case the glob pattern is too broad so that might become a problem.

[jamestalmage]

I think what @sindresorhus is getting at is the following.

If the glob pattern matches a directory explicitly:

$ ava tests/some-dir

What the user almost certainly meant was:

$ ava test/some-dir/*.js

So we help them out and do that automagically.

If the users glob pattern is specific about extensions:

$ ava test/some-dir/*.jsx

Then we take them at their word. In the above example, .js files _should_ be ruled out. If they want .js as well, they need to do:

$ ava test/some-dir/*.{js,jsx}

So basically, we should be using strict glob pattern matching except in the case where they explicitly match a directory.

[sindresorhus]

Yes, that's what I meant, and much clearer :)

Nitpick, but it's recursive: $ ava test/some-dir/*.js => $ ava test/some-dir/**/*.js

[novemberborn]

Cool. What do we do about these lines though: https://github.com/sindresorhus/ava/blob/ad02c321ca5b537b59373643143575d1aea63adb/api.js#L334, https://github.com/sindresorhus/ava/blob/ad02c321ca5b537b59373643143575d1aea63adb/lib/watcher.js#L336.

[novemberborn]

Without getting into #229 territory we can quite easily support .jsx test files and automatically include the react preset. I suspect this would make AVA much easier to use for React projects. @kentcdodds?

[kentcdodds]

I know that some people use .jsx, but I know more people who just use .js. I think that both should be supported. But I don't know if it'll make it any easier for most people. There are already plenty of steps people must follow to get AVA testing their React stuff.

[novemberborn]

@kentcdodds happy to accept a PR that adds React's test naming convention, if that removes a step.

I don't think we should apply the react transform to all .js files. Still we could find ways to make that work out of the box, perhaps #619.

[kentcdodds]

React's test naming convention

There are many of these. Not really React specific. Definitely preference based.

I definitely don't believe that we should arbitrarily add plugins and presets to AVA's built-in config. I just mean that if there is an existing babel configuration, users of AVA are obviously transpiling with babel and will assume that the test files will be transpiled in the same way as their source files.

Maybe having an init with informative questions would be helpful?

[novemberborn]

There are many of these. Not really React specific. Definitely preference based.

Well you got nyc to exclude some patterns (https://github.com/bcoe/nyc/pull/199). Conversely maybe AVA should include them.

---

I definitely don't believe that we should arbitrarily add plugins and presets to AVA's built-in config.

Yea. Still, .jsx is pretty clear-cut IMO.

Maybe having an init with informative questions would be helpful?

:+1:

[kentcdodds]

Well you got nyc to exclude some patterns (bcoe/nyc#199). Conversely maybe AVA should include them.

Ah, I think I misunderstood you. You mean so I don't have to do:

"test": "ava \"app/**/*.test.js\""

But instead I can:

"test": "ava"

That'd be awesome! I'll look into making a PR for that :-)

Yea. Still, .jsx is pretty clear-cut IMO.

Also misunderstood you on this one as well. You're totally right. If they're using .jsx, it would definitely make sense to slap the react preset on there :+1:

[novemberborn]

@sindresorhus @jamestalmage @vdemedes what's your stance on supporting .jsx test files out of the box, including the react transform?

[novemberborn]

Also, while we could support alternative extensions they'll still be treated as JavaScript. IMO that has less value than supporting .jsx.

[sindresorhus]

@novemberborn What about those using JSX and React with a .js extension? I guess we shouldn't run the React transform on everything.

[novemberborn]

I guess we shouldn't run the React transform on everything.

@sindresorhus indeed. My proposal is to add support for .jsx test files (update all locations where we're currently looking for .js test files) and _only_ for .jsx test files add the react transform.

[azizhk]

I guess we shouldn't run the React transform on everything.

Exactly my use case. We have a very big repo and we recently shifted to using ES2015 with react.
If we enabled babel-core/register, our init would slow down (Even watching and saving to a different location + nodemon was slow). We used babel's only option to transpile only *.jsx files. (https://babeljs.io/docs/usage/options/). So now our developers follow this convention of writing ES5 code in *.js files but are enabled to write ES2015 code in *.jsx files.

I wanted to use the same convention in writing test cases, ES2015 code in *.jsx files but ava does not run them 😢

[jamestalmage]

@azizhk - We don't transpile your sources at all. Only your test files.

For sources, instead of nodemon / babel-register - try something like this.

If you just want to be able to use JSX in your tests - that is easier. Just configure AVA's transpiler to use babel in package.json:

{
  "ava": {
    "babel": "inherit" // assuming you have a `.babelrc`,
     // or
    "babel": {
      "presets": ["es2015", "stage-2", /*... whatever presets you want */],
      "plugins": [/* your plugins here */]
    }
  }
}

You still won't be able to use the .jsx extension, but just use .js, then you will be able to use the code constructs you want.

[joakimbeng]

Perhaps an ext flag/option like ESLint has would be a good solution? Which defaults to .js.

So:

ava --ext .js --ext .jsx

Would run both .js and .jsx files... That would require only small changes to the lines mentioned in @novemberborn's comment (I think).

[novemberborn]

@joakimbeng running .jsx without also transpiling React isn't very useful though. We should commit to automatically transpliling .jsx test files with React support, and then allowing for test files with either .js or .jsx extension.

[niieani]

This would make it possible to use an alternative transpiler, like Typescript instead of Babel (using "require": "ts-node/register").

[novemberborn]

@niieani no, just allowing the extension won't magically let AVA transpile TypeScript tests.

[niieani]

@novemberborn of course it will as long as you use the ts-node/register require hook which I mentioned in my comment. As a workaround I'm currently writing tests like this:

test.js:

require('./actual-test.ts')

While actual-test.ts is the actual test file written in TypeScript.

This works but as you can see its really messy because I need to create these one-line files for every test. The only thing needed to solve this is allowing AVA to load files with the .ts extension.

[DrewML]

running .jsx without also transpiling React isn't very useful though

and

and only for .jsx test files add the react transform.

@novemberborn Small note on that - it's fairly common to use JSX without React at this point - see this and this

[niieani]

Any updates on this? Seems like a simple fix.

[novemberborn]

Small note on that - it's fairly common to use JSX without React at this point - see this and this

@DrewML oh dear.

Does that mean .jsx files need their own Babel configuration? Or do the plugins refuse to transpile .js files?

[stoffeastrom]

I commented out the path.extname(file) === '.js' and now my dummy ts test file passes

package.json

  "ava": {
    "files": [
      "test/**/*.ts"
    ],
    "tap": false,
    "require": [
      "ts-node/register"
    ]
  }

As other stated, it seems like a simple fix?

[niieani]

@stoffeastrom yes! @jamestalmage Any ideas about when this change could be merged upstream?

[tjoskar]

@stoffeastrom, if I do the same and adds some typescript specific code like an enum, I get a syntax error:

SyntaxError

1. Uncaught Exception
   SyntaxError: test.ts: Unexpected token (3:5)
  1 | import { test } from 'ava';
  2 |
> 3 | enum testEnum {
    |      ^
  4 |     a = 1
  5 | }
  6 |
at Parser.pp.raise (node_modules/babylon/lib/parser/location.js:22:13)
...

However, if I try to run the following typescript test:

import { test } from 'ava';

let num = 1;

test('should test something', t => {
    num = '1';
    t.is(num, '1');
});

I get the following error:

test.ts (6,5): Type 'string' is not assignable to type 'number'. (2322)
test.ts (7,5): The type argument for type parameter 'U' cannot be inferred from the usage. Consider specifying the type arguments explicitly.

So it seems to me like babel kicks in first and then the typescript compiler. We need a way to disable babel.

[niieani]

@tjoskar looks like you didn't install ts-node locally, it has nothing to do with Babel. It works perfectly on my end with whole TypeScript code-bases.

[tjoskar]

@niieani, as you can see in my second example, the typescript compiler gives an error since I try to change type on the variable num so the typescript compiler works fine :)

My understand is that ava always runs the test throw babel (https://github.com/avajs/ava#es2015-support) and that babel run before any another requirer hook (like "ts-node/register") or I'm wrong?

@niieani, are you able to run the following (typescript) test case:

import { test } from 'ava';

enum testEnum {
    a = 1
}

test('should login', t => {
    t.true(testEnum.a === 1);
});

[niieani]

@tjoskar try using vanilla AVA (without changes) and then make two test files: test.ts (the one you cited above) and test.js. The contents of test.js is one line only:

require('./test.ts');

Now run AVA with the ts-node/register hook, pointing it to test.js. It works in that case. I haven't tried editing AVA manually as suggested, but I don't see why would it be any different (I might be wrong though).

[tjoskar]

@niieani, requiring a typescript file inside a .js file will work since ava only transpile the test files.

It feels like we have lost focus from the issue but I want to clarify what I meant.

Let's say we change the code to accept any file extensions, babel will still try to compile the test. even if we register the ts-node/register hook. eg. source => babel => typescript => ava. See: https://github.com/avajs/ava/blob/ca800ebd2bf8a5ba47ec26cdeaf977e99898bc3f/api.js#L50

This may not be a problem if you don't use any typescript specific code, like enum or interfaces, in your test files.

Take a look at this example:

// test.ts
import { test } from 'ava';

let num = 1;

test('should test something', t => {
    t.is(num, 1);
});

ava => babel (ok) => typescript (ok) => ava (ok)

That will work fine since that is valid javascript code.
Now, look at the following example, where I try to change data type on the num variable.

// test.ts
import { test } from 'ava';

let num = 1;

test('should test something', t => {
    num = '1';
    t.is(num, '1');
});

ava => babel (ok) => typescript (error)

Babel will transpile it to ES5 which is fine and then give the source files to typescript which will complain on num = '1' and give the following error: test.ts (6,5): Type 'string' is not assignable to type 'number'. (2322) which is great and a sign that typescript doing its thing.

Now, look at the following example, where I use typescript specific code.

// test.ts
import { test } from 'ava';

enum testEnum {
    a = 1
}

test('should test something', t => {
    t.true(testEnum.a === 1);
});

ava => babel (error)

Babel will fail here since it doesn't understand enum and don't know what to do with it.

So we need a way to disable babel if we want to use another compiler. Maybe by setting babel: false as @jamestalmage suggested: https://github.com/avajs/ava/issues/631#issuecomment-198519637.
I made a dirt quick fix (as a proof of concept) and replaced these lines: https://github.com/avajs/ava/blob/ca800ebd2bf8a5ba47ec26cdeaf977e99898bc3f/lib/caching-precompiler.js#L82-88 with:

return function(src, filePath) {
    fs.writeFileSync(filePath, src);
};

and after that I could use ava to run my typescript test :tada:

So... We need a way to specify what extension we should use. I think this solutions is great: https://github.com/avajs/ava/issues/631#issuecomment-198973019 and we need to be able to disable babel, without breaking changes.

[niieani]

@tjoskar I stand corrected! Perhaps instead of disabling Babel, we could add this babel plugin: https://www.npmjs.com/package/babel-plugin-transform-flow-strip-types.
It can be used successfully to remove all the TypeScript and Flow annotations from files. If AVA needs to compile the files on its own, she can.

[LiTiang]

@niieani so at now, we still could not just use "require": "ts-node/register

with "files": [test.spec.ts], then work easily as magic ?

[niieani]

@LiTiang not sure I understand what you're asking.

[huan]

@niieani I think what @LiTiang asking, is the same question as I have:

1. we have a test file named: case.spec.ts
2. we want to run case.spec.ts directly(without any pre-compile). if we use ts-node, we can run it by ts-node case.spec.ts
3. we try to run ava --require ts-node/register case.spec.ts, but failed by the message:

1 exception
✖ Couldn't find any files to test

I had looked through the issues, it seems this is a feature that we will support in the future version? looking forward for that.

[dmisdm]

Id really rather not have to get webpack to compile .js files using typescript.
This is from ava-files

// Like in api.js, tests must be .js files and not start with _
if (path.extname(filePath) !== '.js' || path.basename(filePath)[0] === '_') 
        return false;
    }

Is there some rationale behind this that i haven't picked up?

[novemberborn]

Let's go for @joakimbeng's suggestion (https://github.com/avajs/ava/issues/631#issuecomment-221805713):

Perhaps an ext flag/option like ESLint has would be a good solution? Which defaults to .js.

Yes, extensions in the config. No CLI flags, as per #1048. Default to .js, so if you want to support both .js and .jsx you'd need "extensions": [".js", ".jsx"] in the config.

Note that AVA will still assume the test files contain _JavaScript_. This is not yet a solution for supporting TypeScript test files out of the box, though you could run AVA via ts-node as a workaround.

[huan]

I think the goal of this issue Allow tests files to have any extension (i.e..jsx,.ts) is quite straight forward.

and the solution should be very easy to compatible with an extension other than the default(and forced) js: comment out the line limit to .js ext.

and about the other technics, i.e. cache from ava main process, I think I can accept that it be disabled if that will cause a problem when use ts ext.

we should stop sticking here. because now I still can not use ts-node ava test/*.ts to run typescript tests. :(

so I have to use back to tap in my new project.

this is how to run typescript with ts-node in tap, hope it can help others:
https://github.com/tapjs/node-tap/issues/313#issuecomment-250067741

[niieani]

@zixia This being unsolved for such a long time made me give up on AVA and consider alternatives, including Tap. In the end I've switched to the shiny new Jest, which offers pretty much everything that AVA does and then some (e.g. snapshot testing), plus benchmarks show it runs tests even faster.

I still wish AVA all the best and hope it becomes even better than Jest in the future, but keeping AVA JS-only has definitely taken its toll on its popularity by alienating the TypeScript and React communities.

[huan]

@niieani thanks! definitely I want to have Jest a try.

[sindresorhus]

@niieani You can already use TypeScript by precompiling it. I know it's not optimal, but it's not like anyone has done a pull request fixing this. Keep in mind that we all do this in our free time and give it away for free, and we have to prioritize what to work on. Jest is a good choice too. They have the benefit of having multiple full-time Facebook employees working on it. Jest is currently faster for testing React things, since it doesn't run tests in multiple processes. We're working hard on solving this, but could always use some help. We also have no qualms with people switching. Use whatever works the best for you.

@skovhus made this great codemod to make it easier to switch from AVA to Jest: https://github.com/skovhus/jest-codemods

And if you want to help make AVA more performent for React testing, @novemberborn could use some feedback on cached-module-loader.

but keeping AVA JS-only has definitely taken its toll on its popularity by alienating the TypeScript and React communities.

I think alienating is the wrong word here. It's not like we're intentionally blocking out TypeScript and React users. Testing React things works already. Many happily use it. The main culprit is slower test time when using babel-register because it circumvents our cache. Using $ ava --watch makes that less of a problem, as it only reruns changed tests.

[niieani]

Hey @sindresorhus thanks for the reply!

I totally understand time constraints of a free OSS project, I'm on the same bandwagon, so I feel with you. I do not use React too much, so the main reason was having no way to use AVA without a precompilation step. I feel I lost much of the ease and flexibility that were the main reasons to use AVA. Maybe I'm a bit of a cleanness-freak, but I don't like the extra crust and time caused by additional files being generated just for testing + having to concurrently run tsc --watch and ava --watch.

I agree, alienating implies conscious action, so it was wrong for me to use it; perhaps just neglecting, as in not prioritizing TypeScript users, would be better. Anyway, I could probably help out with a PR for this, if I knew how best to solve this :)

Wish AVA and the team all the best! ❤️
You've disrupted the testing packages "market", so having good quality competition like Jest can only help move it forward even more.

[huan]

I'm writing a hack for support to run typescript without precompiling. Please see #1109 :)

[nkoder]

I see a lot about JSX here. But what about ES6? I mean I have project with both JSX and ES6 files, and I write them in IntelliJ. In IntelliJ you can set one JavaScript language per whole project or (what I prefer) you can hint IDE about language by extension. Therefore .es6 is recognized as EcmaScript 6 and .jsx as JSX. Therefore I do not want to write my AVA tests in ES6 and name them with .js extension.

[novemberborn]

@nkoder did you see #1159? That's the direction I'd like to take this in. I haven't made any allowances though for configuring Babel differently depending on the extension (mostly since Babel itself does not support this).

[rauschma]

My use case is: transpiling .mjs files via Babel until Node.js supports them natively. Alas, with this config, AVA does not find any files in test/:

  "ava": {
    "require": [
      "babel-register"
    ],
    "files": [
      "test/**/*.mjs"
    ],
    "babel": "inherit"
  }

What’s the harm in making .js the default, but allowing arbitrary custom file extensions?

[huan]

@rauschma No, this will not work because of the AvaFiles. See also: https://github.com/avajs/ava-files/pull/9

[novemberborn]

@rauschma this is blocked on the implementation of RFC 001, see the project overview. I've been focused on https://github.com/avajs/ava/pull/1341 instead.

[rauschma]

Cool, that would do exactly what I need (via babel.extensions)! Maybe add an explanation for what happened to the property inherit?

Without babel.extensions, I can’t currently work with AVA, because I even get errors if I mention files directly:

> ava "test/first-module_test.mjs"
  ✖ Couldn't find any files to test

[novemberborn]

Maybe add an explanation for what happened to the property inherit?

Yea we'll document how to migrate to this new config.

Without babel.extensions, I can’t currently work with AVA, because I even get errors if I mention files directly:

Re-reading the RFC 001 and some of the discussion in this thread I think we can land support for babel.extensions now, without any of the other proposed changes. Specifying it under babel is paramount, as it conveys these files are transpiled using Babel.

I'll remove the blocked label. If anybody wants to pick this up that'd be great.

[rauschma]

Awesome! If you do babel.extensions, I suspect you need to support babel.inherit (or similar), too, given that babel: "inherit" can’t be specified, anymore.

[novemberborn]

Good point. We should make sure to retain compatibility with the current use of the babel options (until we change it all as part of RFC 001).

[rauschma]

An easy preliminary solution would be to introduce a property babel.value that takes over the role that babel had, previously.

[Jamesernator]

I'd like to see this so that @std/esm can be used to run ESM tests e.g.:

// test.mjs
import test from "ava"
import foo from "../esm.mjs"

test(t => {
    t.is(foo(), 2)
})

// esm.mjs
export default function foo() {
    return 2
}

// package.json
{
    "ava": {
        "require": ["@std/esm"]
    }
}

Given that .mjs is going to be the way to distinguish ESM from CommonJS in Node this should be supported even without a more generic way of supporting other extensions.

[novemberborn]

@Jamesernator there's an ongoing discussion around @std/esm in https://github.com/avajs/ava/issues/1512.

[cameron-martin]

This will become even more important once babel 7 is released, which has the ability to parse and remove the type annotations from Typescript files.

[vanga]

Hello,

I want to use ava for server-side(Coffee-Script) testing, I want to write tests also in Coffee. Based on my searching around, I see that there are ways to achieve this. Some posts suggest to use --require, but that seems to have been deprecated.

{
"ava": {
"require": "coffee-script/register",
"babel": false,
"files": "test/*/.coffee"
}
}

Is this still relevant? I tried to do something like this and was unsuccesful.

Can someone please tell me if what I am trying to do is possible and point me in the right direction if it is possible.

Thanks.

[novemberborn]

@vanga AVA performs some transpilations on the test files. These assume the test files contain JavaScript. Until those transpilations can be disabled we cannot support arbitrary file extensions, or indeed support non-JavaScript test files.

[vanga]

Thanks @novemberborn
I guess I will try having a wrapper that compiles coffee script test files to JS before starting ava tests. That's enough for me if it works.

[feross]

@vanga AVA performs some transpilations on the test files. These assume the test files contain JavaScript. Until those transpilations can be disabled we cannot support arbitrary file extensions, or indeed support non-JavaScript test files.

Makes sense. But why can't .mjs be treated as JavaScript? That extension will always contain JavaScript. ava won't run tests even when specifying an .mjs file explicitly, which is preventing the testing of ES Module code:

$ ava test/basic.mjs

  1 exception

  ✖ Couldn't find any files to test

cc @jdalton

[novemberborn]

@feross I think we could recognize .mjs files, yes. We'd have to properly resolve imports and enforce strict mode though. I'd accept a PR for that, separate from completely disabling Babel and supporting an extensions option.

[feross]

@novemberborn That's great to hear! I was just investigating porting tests from tape to ava for a few minutes, so I'm not invested enough in ava yet to dig into the code to send a PR. Hopefully someone who's more familiar can jump in and try this?

[novemberborn]

Our globbing is quite broken but after I land #1608 I intend to implement extensions for our Babel pipeline, and probably top-level too which would let you specify which file extensions should be recognized by AVA without Babel compilation. (If these are not JS files you'd have to disable the new compileEnhancements flag.)

[Jaden-Giordano]

@novemberborn Do we have an update on this issue?

[novemberborn]

@Jaden-Giordano I've been focused on landing other improvements and breaking changes in preparation for a 1.0 release. That said we have enough pieces in place for extensions to be added. If you'd be willing to land a hand that'd be great.

[Jaden-Giordano]

@novemberborn So really the only issue is that ava is filtering based on the extensions hard coded:
https://github.com/avajs/ava/blob/master/lib/ava-files.js#L60
We shouldn't need to filter since the glob already handles that with the comma separated lists, i.e. **/*.{js,jsx}. I say we should just remove this line it should work just fine. Let me know what you think and I'll create the PR if you approve.

Edit:
Just tested it out by removing the line and setting the files option to tests/**/*.{js,jsx}; it finds all the files and runs all the tests. Here is the test directory I used:

tests/
-a/
--test-in-folder.js
--react-test-in-folder.jsx
-test.js
-react-test.jsx

I'm going to make the pull request so we can fine tune it there.

[novemberborn]

@Jaden-Giordano it's not that easy I'm afraid. We need to hook this up to our Babel pipeline, and separately our compiled enhancements. (Though currently those are implemented using the Babel pipeline, say when we bring in TypeScript we may have a TypeScript-specific implementation.)

So ava.babel.extensions = [] should contain test file extensions to which the Babel pipeline is applied, as well as the compiled enhancements. ava.extensions = [] should contain test file extensions to which only the compiled enhancements are applied. To avoid ambiguities you shouldn't be allowed to specify the same extension in both lists. Also, we need to make sure the watcher recognizes these new extensions.

We need this refinement so you can specify ava.extensions = ['.ts'] and automatically opt-out of Babel compilation. Though until we have full TypeScript support you'll also have to set ava.compileEnhancements = false.

[Jaden-Giordano]

So basically ava.babel.extensions should precompile with the CachingPrecompiler and ava.extensions should opt-out of that? Which would mean the writer of the tests utilizing ava.extensions would need to precompile the tests themselves. Is that the intended flow?

Edit:
Also are we allow both extension providers to be used? If so, you mentioned not allowing the same extension in each so we can throw an error in that case.

[Jaden-Giordano]

@novemberborn

[novemberborn]

So basically ava.babel.extensions should precompile with the CachingPrecompiler and ava.extensions should opt-out of that?

Yes, albeit with the nuance that the compileEnhancement setting is currently implemented through the precompiler. It's a bit roundabout, I know.

Which would mean the writer of the tests utilizing ava.extensions would need to precompile the tests themselves.

The test files may not even need precompiling, or alternatively you might use use something like ts-node/register to compile them on the fly.

[jamesthurley]

To help those looking for what you need to change now this issue is closed:

With AVA version 1.0.0-beta.5.1 I used the following settings to successfully run my .ts tests:

    "babel": false,
    "extensions": [
      "ts"
    ],
    "require": [
      "ts-node/register"
    ]

Thanks @novemberborn and @Jaden-Giordano for getting this working!

[novemberborn]

If anybody's game for updating the TypeScript recipe that'd be great. See https://github.com/avajs/ava/issues/1822 ❤️