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

Support to Run TypeScript test file(.ts) directly without Precompiling(tsc) #1109

Open
zixia opened this Issue Nov 15, 2016 · 50 comments

Comments

Projects
None yet
@zixia

zixia commented Nov 15, 2016

Description

AVA now support ES6 by using Babel, run directly without any precompiling, this is very convenience. But for TypeScript, AVA has to precompile ts files by run tsc.

I use TypeScript in my project wechaty, run TS code directly by ts-node like this: ts-node demo.ts. This is a convenience way for developing.

If we can run TypeScript file directly by AVA, just like ava test.ts, that will be wonderful.

About this topic, there has already an issue #631 on it. I saw @sindresorhus agree that use TypeScript without precompiling is a better way.

@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. #631 (comment)

I love AVA, because I'm a TAP fan, and AVA is based on TAP. So I tried to hack AVA to support TypeScript directly. After some study & work, I finished it finally, and in the past month, I was using it in my own project and it worked as my expected.

I'll share my idea here, and send a Pull Request later. Hope we can support TypeScript without precompiling soon.

ava-typescript

About the Hack

I added a --ext ts argument parameter to CLI, then pass ext to AVA API. If ext is ts then I use TypeScript Compiler to replace the Babel Compiler, because TypeScript is the superset of ES6/7.

  1. Add CLI Arg: --ext/-e

    In order to support TypeScript without precompiling, first, we need to add a CLI args to support that. I use the name --ext and the alias -e for this, like ava -e ts. Set the ext automatically is considered, but I think maybe it should be done later. If set ext automatically, then we can just run TS tests by ava test.ts

  2. Get Test Files from ava-files

    AVA use a submodule ava-files to get all test files list. It had to be modified to support the ext parameter. I use exts in the ava-files module and it is an Array type, that's for the future support of multiple file extensions.

  3. new API options: ext

    in API call, we get file extension name from options.ext, pass it to AvaFiles/CachingPrecompiler/Watcher.

  4. Add a Switcher between Babel with TypeScript

    AVA compile ES6 by Babel in CachingPrecompiler, so we could compile TypeScript here. If the file extension is set to ts, then CachingPrecompiler will use a new module extTs to compile the source.

  5. Introduce a new Module: extTs(lib/ext/ts.js)

    For ts file extension, the compiler module ext/ts.js will be loaded. In the furture, other extension could modulize their own compile code in different file in ext/ directory. i.e. ext/jsx.js for a new extJsx compiling module.

  6. Enable Run TypeScript in test-worker.js

    AVA use subprocess to run tests, the worker needs to register to TypeScript compiler.

  7. Add TypeScript dependence to package.json

  8. Make XO happy

Test Source

test.ts:

import { test } from 'ava'

test('AVA run TypeScript without tsc', t => {
  let i: number = 42
  t.is(i, <number>42, 'meaning of life')
})

Run:

$ ava --ext ts test.ts

  ✔ AVA run TypeScript without tsc

  1 test passed [02:55:58]

Yeah~

Relevant Links

@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Nov 16, 2016

Hi,

Is there any feedback or suggestion?

I want to know:

  1. is the parameter name all right? now they are:
    1. --ext / -e for AVA CLI
    2. exts a new key for AvaFile options
  2. how about to set --ext automatically? if we run ava test.ts then let ava know .ts should support typescript.

looking forward to getting feedback, then I can make the Pull Request fit better.

zixia commented Nov 16, 2016

Hi,

Is there any feedback or suggestion?

I want to know:

  1. is the parameter name all right? now they are:
    1. --ext / -e for AVA CLI
    2. exts a new key for AvaFile options
  2. how about to set --ext automatically? if we run ava test.ts then let ava know .ts should support typescript.

looking forward to getting feedback, then I can make the Pull Request fit better.

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Nov 20, 2016

Member

Thanks for picking this up @zixia :)

Your proposal looks pretty good.

Some random feedback:

  • It should be possible to set --ext multiple times.
  • .js files should always be included.
  • TypeScript should not be a dependency of AVA, but rather in the user's package.json. If it's not, we should throw a friendly error message. We bundle Babel because we depend on it in AVA for other things too.
  • Setting extension automatically works fine when you specify exact files, but most users specify globs, so not sure whether it's worth the inconsistency of only working in some cases.
  • I think --extension/-e CLI flag and extensions option name would be better.
  • Make sure you handle caching correctly.
Member

sindresorhus commented Nov 20, 2016

Thanks for picking this up @zixia :)

Your proposal looks pretty good.

Some random feedback:

  • It should be possible to set --ext multiple times.
  • .js files should always be included.
  • TypeScript should not be a dependency of AVA, but rather in the user's package.json. If it's not, we should throw a friendly error message. We bundle Babel because we depend on it in AVA for other things too.
  • Setting extension automatically works fine when you specify exact files, but most users specify globs, so not sure whether it's worth the inconsistency of only working in some cases.
  • I think --extension/-e CLI flag and extensions option name would be better.
  • Make sure you handle caching correctly.
@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Nov 21, 2016

Got it.

I'll follow your great feedback then make the PR later. :)

  • It should be possible to set --ext multiple times.
  • .js files should always be included.
  • TypeScript should not be a dependency of AVA, but rather in the user's package.json. We bundle Babel because we depend on it in AVA for other things too.
  • If it's not, we should throw a friendly error message.
  • Setting extension automatically works fine when you specify exact files, but most users specify globs, so not sure whether it's worth the inconsistency of only working in some cases.
  • I think --extension/-e CLI flag and extensions option name would be better.
  • Make sure you handle caching correctly.

zixia commented Nov 21, 2016

Got it.

I'll follow your great feedback then make the PR later. :)

  • It should be possible to set --ext multiple times.
  • .js files should always be included.
  • TypeScript should not be a dependency of AVA, but rather in the user's package.json. We bundle Babel because we depend on it in AVA for other things too.
  • If it's not, we should throw a friendly error message.
  • Setting extension automatically works fine when you specify exact files, but most users specify globs, so not sure whether it's worth the inconsistency of only working in some cases.
  • I think --extension/-e CLI flag and extensions option name would be better.
  • Make sure you handle caching correctly.
@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Nov 21, 2016

Hi @sindresorhus ,

I had followed all your feedbacks and made two PRs: one is for AvaFiles, the other is for AVA.

Please notice that CI for AVA will be expected to report failure because the ava-files NPM modules do not support extensions parameter now.

All unit tests had passed in my dev box with the PR code.

Please let me know if I missed anything in PR, thanks.

zixia commented Nov 21, 2016

Hi @sindresorhus ,

I had followed all your feedbacks and made two PRs: one is for AvaFiles, the other is for AVA.

Please notice that CI for AVA will be expected to report failure because the ava-files NPM modules do not support extensions parameter now.

All unit tests had passed in my dev box with the PR code.

Please let me know if I missed anything in PR, thanks.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Nov 23, 2016

Contributor

@zixia this is awesome work and I'm excited to use it, but can you tell me if it works fine with the --watch flag too? Or is there more work to do for that?

Contributor

jedmao commented Nov 23, 2016

@zixia this is awesome work and I'm excited to use it, but can you tell me if it works fine with the --watch flag too? Or is there more work to do for that?

@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Nov 24, 2016

@jedmao Hi buddy thanks you for like my work, and I'm sure you are a TypeScript fan like me.

In theory, I think it should work with the --watch flag, because I modified all the parts in AVA to support ts, including Watcher class and all the Watcher unit tests. But I did not test it yet, and there's possible I missed part of it. So if you find any problem with that, please let me know, and I'll get it worked.

If you want to try it before @sindresorhus merge this PR, you can pull my clone at https://github.com/zixia/ava (branch: typescript) , and also don't forget to link ava-files too: https://github.com/zixia/ava-files

zixia commented Nov 24, 2016

@jedmao Hi buddy thanks you for like my work, and I'm sure you are a TypeScript fan like me.

In theory, I think it should work with the --watch flag, because I modified all the parts in AVA to support ts, including Watcher class and all the Watcher unit tests. But I did not test it yet, and there's possible I missed part of it. So if you find any problem with that, please let me know, and I'll get it worked.

If you want to try it before @sindresorhus merge this PR, you can pull my clone at https://github.com/zixia/ava (branch: typescript) , and also don't forget to link ava-files too: https://github.com/zixia/ava-files

@patrick91

This comment has been minimized.

Show comment
Hide comment
@patrick91

patrick91 Feb 11, 2017

Is there any update on this? I'm starting a new TS project and I really would like to use ava without compiling TS scripts first!

@zixia amazing work so far!

patrick91 commented Feb 11, 2017

Is there any update on this? I'm starting a new TS project and I really would like to use ava without compiling TS scripts first!

@zixia amazing work so far!

@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Feb 12, 2017

@patrick91 Thanks!

AVA decide to re-design the total code structure of how to use Babel, which delayed the TypeScript support progress.

See: #1159

zixia commented Feb 12, 2017

@patrick91 Thanks!

AVA decide to re-design the total code structure of how to use Babel, which delayed the TypeScript support progress.

See: #1159

@bitjson

This comment has been minimized.

Show comment
Hide comment
@bitjson

bitjson Feb 13, 2017

@patrick91 (and anyone else coming across this thread) – I've been getting into Typescript a lot recently, and had some trouble getting a lot of the packages I wanted to use working together.

I spent a little time starter project which I think it might accomplish what you're looking for: es7-typescript-starter

  • Write your library and AVA tests in Typescript
  • everything uses tsconfig.json properly (so tooling/build/test settings match)
  • source-mapped code coverage, typedoc API doc generation, etc.
  • type definitions are linked properly for projects depending on yours
  • and there are a few examples of how to use both the main (commonjs) and module (es6 module) output formats

I'd love input/feedback on how it could be improved, especially when AVA restarts work on this issue.

bitjson commented Feb 13, 2017

@patrick91 (and anyone else coming across this thread) – I've been getting into Typescript a lot recently, and had some trouble getting a lot of the packages I wanted to use working together.

I spent a little time starter project which I think it might accomplish what you're looking for: es7-typescript-starter

  • Write your library and AVA tests in Typescript
  • everything uses tsconfig.json properly (so tooling/build/test settings match)
  • source-mapped code coverage, typedoc API doc generation, etc.
  • type definitions are linked properly for projects depending on yours
  • and there are a few examples of how to use both the main (commonjs) and module (es6 module) output formats

I'd love input/feedback on how it could be improved, especially when AVA restarts work on this issue.

@lukescott

This comment has been minimized.

Show comment
Hide comment
@lukescott

lukescott May 27, 2017

@novemberborn I know I can do tsc && ava, but that won't work with --watch, will it? Is there a solution to make it work with watch?

lukescott commented May 27, 2017

@novemberborn I know I can do tsc && ava, but that won't work with --watch, will it? Is there a solution to make it work with watch?

@tomdavidson

This comment has been minimized.

Show comment
Hide comment
@tomdavidson

tomdavidson May 27, 2017

@lukescott you can add "compileOnSave": true to your tsconfig.json if you use an editor that recognizes it. You can also change your watch/dev run script to be something like tsc -w & ava --watch so tsc will watch in the background while you run ava watch.

I think ava is super interesting but I have not replaced mocha over the typescript issue so the suggestion is not in use for me.

tomdavidson commented May 27, 2017

@lukescott you can add "compileOnSave": true to your tsconfig.json if you use an editor that recognizes it. You can also change your watch/dev run script to be something like tsc -w & ava --watch so tsc will watch in the background while you run ava watch.

I think ava is super interesting but I have not replaced mocha over the typescript issue so the suggestion is not in use for me.

@lukescott

This comment has been minimized.

Show comment
Hide comment
@lukescott

lukescott May 27, 2017

Ah, got it. So I need need to run them separately. Tsc will watch and save files, which Ava will pick those up. It's too bad there isn't a way to do a single watcher and have it all happen in memory.

lukescott commented May 27, 2017

Ah, got it. So I need need to run them separately. Tsc will watch and save files, which Ava will pick those up. It's too bad there isn't a way to do a single watcher and have it all happen in memory.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao May 27, 2017

Contributor

Yep, I've been waiting for the same feature.

Contributor

jedmao commented May 27, 2017

Yep, I've been waiting for the same feature.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn
Member

novemberborn commented May 29, 2017

The plan is here, but there hasn't been progress on that lately: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md

@unional

This comment has been minimized.

Show comment
Hide comment
@unional

unional Jun 21, 2017

@lukescott for watch, you can do this:
https://github.com/unional/color-map/blob/master/scripts/watch.js

'use strict';

const cp = require('child_process');

let ava;
cp.spawn('tsc', ['-w'], { shell: true })
  .stdout.on('data', (data) => {
    if (!ava) {
      ava = cp.spawn('ava', ['-w'], {
        stdio: 'inherit',
        shell: true
      })
    }
    const text = data.toString()
    process.stdout.write(text)
    if (/.*Compilation complete/.test(text)) {
      let lint = cp.spawnSync('npm', ['run', 'lint'], {
        stdio: 'inherit',
        shell: true
      })
      if (lint.status === 0) {
        cp.spawnSync('npm', ['run', 'build-commonjs'])
      }
    }
  })

unional commented Jun 21, 2017

@lukescott for watch, you can do this:
https://github.com/unional/color-map/blob/master/scripts/watch.js

'use strict';

const cp = require('child_process');

let ava;
cp.spawn('tsc', ['-w'], { shell: true })
  .stdout.on('data', (data) => {
    if (!ava) {
      ava = cp.spawn('ava', ['-w'], {
        stdio: 'inherit',
        shell: true
      })
    }
    const text = data.toString()
    process.stdout.write(text)
    if (/.*Compilation complete/.test(text)) {
      let lint = cp.spawnSync('npm', ['run', 'lint'], {
        stdio: 'inherit',
        shell: true
      })
      if (lint.status === 0) {
        cp.spawnSync('npm', ['run', 'build-commonjs'])
      }
    }
  })
@sebinsua

This comment has been minimized.

Show comment
Hide comment
@sebinsua

sebinsua Jun 29, 2017

The plan is here, but there hasn't been progress on that lately: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md

Has there been any work on this since then?

sebinsua commented Jun 29, 2017

The plan is here, but there hasn't been progress on that lately: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md

Has there been any work on this since then?

@patrick91

This comment has been minimized.

Show comment
Hide comment
@patrick91

patrick91 Jun 29, 2017

babel has recently merged a PR that allows to parse typescript, so maybe soon enough we will be able to use ava for typescript via babel :)

babel/babylon#523 (comment)

patrick91 commented Jun 29, 2017

babel has recently merged a PR that allows to parse typescript, so maybe soon enough we will be able to use ava for typescript via babel :)

babel/babylon#523 (comment)

@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Jun 30, 2017

Looking forward it, or I have to consider other solutions like tap which had already supported the TypeScript(tapjs/node-tap#313) and Concurrency.

zixia commented Jun 30, 2017

Looking forward it, or I have to consider other solutions like tap which had already supported the TypeScript(tapjs/node-tap#313) and Concurrency.

@ORESoftware

This comment has been minimized.

Show comment
Hide comment
@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Jul 1, 2017

Member

If we can run TypeScript through Babel then yea we can land some sort of support for that. Though you'd still need the equivalent to babel-register to load TypeScript source files.

Member

novemberborn commented Jul 1, 2017

If we can run TypeScript through Babel then yea we can land some sort of support for that. Though you'd still need the equivalent to babel-register to load TypeScript source files.

@lukescott

This comment has been minimized.

Show comment
Hide comment
@lukescott

lukescott Jul 1, 2017

With TypeScript support in babel, wouldn't babel-register (or what ever Ava uses) work? I would imagine babel adding the .ts extension w/ native support.

lukescott commented Jul 1, 2017

With TypeScript support in babel, wouldn't babel-register (or what ever Ava uses) work? I would imagine babel adding the .ts extension w/ native support.

@adieuadieu

This comment has been minimized.

Show comment
Hide comment
@adieuadieu

adieuadieu Jul 5, 2017

I came to this thread/issue while trying to use Ava's --watch feature with TypeScript. @tomdavidson's suggestion of tsc --watch & ava --watch works well enough as an intermediate solution for anyone who wants to watch their TypeScript code for changes and rerun those tests.

adieuadieu commented Jul 5, 2017

I came to this thread/issue while trying to use Ava's --watch feature with TypeScript. @tomdavidson's suggestion of tsc --watch & ava --watch works well enough as an intermediate solution for anyone who wants to watch their TypeScript code for changes and rerun those tests.

@bitjson

This comment has been minimized.

Show comment
Hide comment
@bitjson

bitjson Jul 5, 2017

If anyone is interested, the solution @adieuadieu mentioned (from @tomdavidson) is what typescript-starter uses right now.

bitjson commented Jul 5, 2017

If anyone is interested, the solution @adieuadieu mentioned (from @tomdavidson) is what typescript-starter uses right now.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Sep 3, 2017

Member

I'm closing this issue since it's not directly actionable.

Our plan for making AVA precompiler-agnostic can be found here: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md — we'll need help achieving that.

Further, we'd be willing to support TypeScript test files sooner if we can run them through our existing Babel infrastructure.

Member

novemberborn commented Sep 3, 2017

I'm closing this issue since it's not directly actionable.

Our plan for making AVA precompiler-agnostic can be found here: https://github.com/avajs/ava/blob/master/docs/specs/001%20-%20Improving%20language%20support.md — we'll need help achieving that.

Further, we'd be willing to support TypeScript test files sooner if we can run them through our existing Babel infrastructure.

@aendrew

This comment has been minimized.

Show comment
Hide comment
@aendrew

aendrew Sep 21, 2017

How difficult would be it be to just add the "extension" whitelist option? It seems like that plus ts-node/register in the require config stanza would be sufficient to make this possible.

aendrew commented Sep 21, 2017

How difficult would be it be to just add the "extension" whitelist option? It seems like that plus ts-node/register in the require config stanza would be sufficient to make this possible.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Sep 24, 2017

Member

Just adding the extension support makes it quite hard to understand which of AVA's behaviors is actually available, and as you say it requires further customizations to make the tests work. We want to land first-class support for TypeScript. We know how, but the work hasn't been done yet.

Member

novemberborn commented Sep 24, 2017

Just adding the extension support makes it quite hard to understand which of AVA's behaviors is actually available, and as you say it requires further customizations to make the tests work. We want to land first-class support for TypeScript. We know how, but the work hasn't been done yet.

@kirillgroshkov

This comment has been minimized.

Show comment
Hide comment
@kirillgroshkov

kirillgroshkov Sep 28, 2017

I want to vote on this feature!

kirillgroshkov commented Sep 28, 2017

I want to vote on this feature!

@andywer

This comment has been minimized.

Show comment
Hide comment
@andywer

andywer Oct 29, 2017

I know this is an old issue, but I needed the same thing, since a prior build step can be quite ugly.

So I quickly created ava-ts. Give it a try and leave feedback if you want :)

andywer commented Oct 29, 2017

I know this is an old issue, but I needed the same thing, since a prior build step can be quite ugly.

So I quickly created ava-ts. Give it a try and leave feedback if you want :)

@zixia

This comment has been minimized.

Show comment
Hide comment
@zixia

zixia Oct 29, 2017

@andywer You are awesome!

zixia commented Oct 29, 2017

@andywer You are awesome!

@GantMan

This comment has been minimized.

Show comment
Hide comment
@GantMan

GantMan commented Nov 6, 2017

@andywer - super cool! That's epic.
I've already switched though: https://shift.infinite.red/switching-from-ava-to-jest-for-typescript-a6dac7d1712f

Sorry :(

@andywer

This comment has been minimized.

Show comment
Hide comment
@andywer

andywer Nov 6, 2017

@GantMan Thx. Pity, though! Would you mind mentioning ava-ts in your blog post? :)

Btw, thanks for all the great responses. Feel free to spread the word or 🌟 the repo, it feels a bit disregarded 😉

andywer commented Nov 6, 2017

@GantMan Thx. Pity, though! Would you mind mentioning ava-ts in your blog post? :)

Btw, thanks for all the great responses. Feel free to spread the word or 🌟 the repo, it feels a bit disregarded 😉

@GantMan

This comment has been minimized.

Show comment
Hide comment
@GantMan

GantMan Nov 6, 2017

Added!!! And call-to action to star the repo added as well. Great work. Might see you cool kids again later. It seems the curse of JavaScript is that I have to switch libs as soon as I feel comfortable with them. 😆

GantMan commented Nov 6, 2017

Added!!! And call-to action to star the repo added as well. Great work. Might see you cool kids again later. It seems the curse of JavaScript is that I have to switch libs as soon as I feel comfortable with them. 😆

@andywer

This comment has been minimized.

Show comment
Hide comment
@andywer

andywer Nov 7, 2017

@novemberborn Would you consider linking to ava-ts in the TypeScript recipe for the time being? I think that is where most folks will look for help and it makes using AVA with TS noticeably easier.

andywer commented Nov 7, 2017

@novemberborn Would you consider linking to ava-ts in the TypeScript recipe for the time being? I think that is where most folks will look for help and it makes using AVA with TS noticeably easier.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Nov 13, 2017

Member

Hey @andywer! I've been thinking about this, and whilst I'm not adverse to linking to it I'd like to figure out an actionable plan to better support TypeScript directly, so we don't have to promote a fork for too long.

Following up on my earlier comment: #1109 (comment)

Further, we'd be willing to support TypeScript test files sooner if we can run them through our existing Babel infrastructure.

Here's what I think we can do pretty soon, which would provide minimal support for TypeScript. I'd like people's feedback on whether this would suit their needs.

I'm assuming people are OK with using ts-node/register for on-the-fly test file and source file compilation. The reason we didn't want to support .ts file extensions before is that AVA doesn't know not to precompile them using Babel. However we're talking about disabling Babel altogether in (amongst other issues) #1556:

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.

#1556 (comment)

With #1556 out of the way we could add support for an extensions option. AVA would treat matched files with the configured extensions as test files. It won't precompile them so it won't break on .ts files. ts-node/register then takes care of transpilation.

Of course you could still precompile all files like you do now. It'd love for AVA to compile .ts files itself but that'd be follow-up work.

Ideally you wouldn't need to configure extensions either but currently when the globbing rules match directories we look for .js files specifically. I'm sure there are possible improvements but that's for later.

What do folks think about this approach?

Member

novemberborn commented Nov 13, 2017

Hey @andywer! I've been thinking about this, and whilst I'm not adverse to linking to it I'd like to figure out an actionable plan to better support TypeScript directly, so we don't have to promote a fork for too long.

Following up on my earlier comment: #1109 (comment)

Further, we'd be willing to support TypeScript test files sooner if we can run them through our existing Babel infrastructure.

Here's what I think we can do pretty soon, which would provide minimal support for TypeScript. I'd like people's feedback on whether this would suit their needs.

I'm assuming people are OK with using ts-node/register for on-the-fly test file and source file compilation. The reason we didn't want to support .ts file extensions before is that AVA doesn't know not to precompile them using Babel. However we're talking about disabling Babel altogether in (amongst other issues) #1556:

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.

#1556 (comment)

With #1556 out of the way we could add support for an extensions option. AVA would treat matched files with the configured extensions as test files. It won't precompile them so it won't break on .ts files. ts-node/register then takes care of transpilation.

Of course you could still precompile all files like you do now. It'd love for AVA to compile .ts files itself but that'd be follow-up work.

Ideally you wouldn't need to configure extensions either but currently when the globbing rules match directories we look for .js files specifically. I'm sure there are possible improvements but that's for later.

What do folks think about this approach?

@impaler

This comment has been minimized.

Show comment
Hide comment
@impaler

impaler Nov 14, 2017

Contributor

ts-node support sounds like a convenient approach, there are probably other language-node libs that may work the same.

For registering ts-node itself, would you use "require" in the package.json#ava?
Since --require was depreciated from the cli options, is it a limiation now that you can't seem scope what to require for what?

For example say I didn't want to use ts-node or some global browser env for every test I want to use in ava:

"scripts": {
  "test:ts-node": "ava --require helpers/ts-node.js src/**/**.ava.ts",
  "test:ts-browser": "ava --require helpers/ts-browser-env.js src/**/**.ava-browser.tsx"
}
Contributor

impaler commented Nov 14, 2017

ts-node support sounds like a convenient approach, there are probably other language-node libs that may work the same.

For registering ts-node itself, would you use "require" in the package.json#ava?
Since --require was depreciated from the cli options, is it a limiation now that you can't seem scope what to require for what?

For example say I didn't want to use ts-node or some global browser env for every test I want to use in ava:

"scripts": {
  "test:ts-node": "ava --require helpers/ts-node.js src/**/**.ava.ts",
  "test:ts-browser": "ava --require helpers/ts-browser-env.js src/**/**.ava-browser.tsx"
}
@lukescott

This comment has been minimized.

Show comment
Hide comment
@lukescott

lukescott Nov 14, 2017

Babel 7 has support for TypeScript, so all you have to do is use the typescript preset. I've found that enums and namespaces are not supported though. Everything else seems to work great.

In the latest betas they've changed from babel-core to @babel/core, and all the packages are now namespaced under @babel. All the plugins with the word "transform" have been changed to "proposal" and all the config options need to start with @babel/, such as "@babel/env" instead of just "env".

lukescott commented Nov 14, 2017

Babel 7 has support for TypeScript, so all you have to do is use the typescript preset. I've found that enums and namespaces are not supported though. Everything else seems to work great.

In the latest betas they've changed from babel-core to @babel/core, and all the packages are now namespaced under @babel. All the plugins with the word "transform" have been changed to "proposal" and all the config options need to start with @babel/, such as "@babel/env" instead of just "env".

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Nov 14, 2017

Member

For registering ts-node itself, would you use "require" in the package.json#ava?
Since --require was depreciated from the cli options, is it a limiation now that you can't seem scope what to require for what?

@impaler pending 1st class support in AVA itself I think that's how it'd play out, yes. You disable AVA's Babel-powered treatment of test files and rely on language-node libs to transpile test files.

Babel 7 has support for TypeScript, so all you have to do is use the typescript preset. I've found that enums and namespaces are not supported though. Everything else seems to work great.

@lukescott does it do type checking as well, or does it just remove the syntax annotations? Regardless, it might be an option. With what I'm suggesting AVA would still default to applying Babel to test files and it's up to you to ensure Babel doesn't choke. So once we switch to Babel 7 you could go this route if it's the right fit for your project.

Member

novemberborn commented Nov 14, 2017

For registering ts-node itself, would you use "require" in the package.json#ava?
Since --require was depreciated from the cli options, is it a limiation now that you can't seem scope what to require for what?

@impaler pending 1st class support in AVA itself I think that's how it'd play out, yes. You disable AVA's Babel-powered treatment of test files and rely on language-node libs to transpile test files.

Babel 7 has support for TypeScript, so all you have to do is use the typescript preset. I've found that enums and namespaces are not supported though. Everything else seems to work great.

@lukescott does it do type checking as well, or does it just remove the syntax annotations? Regardless, it might be an option. With what I'm suggesting AVA would still default to applying Babel to test files and it's up to you to ensure Babel doesn't choke. So once we switch to Babel 7 you could go this route if it's the right fit for your project.

@btkostner

This comment has been minimized.

Show comment
Hide comment
@btkostner

btkostner Nov 14, 2017

Contributor

I'm not sure how babel has implimented typescript support, but if it's just removing the syntax annotations then some people will run into issues with type metadata. This could potentionally mess with IoC implementations.

I would strongly favor using a language-node package to transpile tests.

Contributor

btkostner commented Nov 14, 2017

I'm not sure how babel has implimented typescript support, but if it's just removing the syntax annotations then some people will run into issues with type metadata. This could potentionally mess with IoC implementations.

I would strongly favor using a language-node package to transpile tests.

@lukescott

This comment has been minimized.

Show comment
Hide comment
@lukescott

lukescott Nov 14, 2017

It just removes the TypeScript specific syntax, similar to what it has already done with Flow. So far it has greatly simplified my build process as I don’t have to pre-process with tsc. I just run TyoeScript in Atom for all the type checking.

I would imagine that the typescript preset would at least allow you to run Ava with TypeScript code. You can use tsc to validate the types are correct.

lukescott commented Nov 14, 2017

It just removes the TypeScript specific syntax, similar to what it has already done with Flow. So far it has greatly simplified my build process as I don’t have to pre-process with tsc. I just run TyoeScript in Atom for all the type checking.

I would imagine that the typescript preset would at least allow you to run Ava with TypeScript code. You can use tsc to validate the types are correct.

@aendrew

This comment has been minimized.

Show comment
Hide comment
@aendrew

aendrew Nov 22, 2017

Re: @lukescott's comment, according to the babel-plugin-transform-typescript docs, import = and export = aren't supported either. This, combined with lack of enums and namespaces, means I'd really be loathe to use it in place of something like ts-node.

FWIW, a number of test tools use ts-node already (NYC, Mocha), so it's a pretty well-established workflow when testing using TS.

aendrew commented Nov 22, 2017

Re: @lukescott's comment, according to the babel-plugin-transform-typescript docs, import = and export = aren't supported either. This, combined with lack of enums and namespaces, means I'd really be loathe to use it in place of something like ts-node.

FWIW, a number of test tools use ts-node already (NYC, Mocha), so it's a pretty well-established workflow when testing using TS.

@jonahbron

This comment has been minimized.

Show comment
Hide comment
@jonahbron

jonahbron Mar 6, 2018

Any recent activity on this? I'm choosing a test runner for a new application, and good TypeScript support is an important part of that decision.

jonahbron commented Mar 6, 2018

Any recent activity on this? I'm choosing a test runner for a new application, and good TypeScript support is an important part of that decision.

@sebinsua

This comment has been minimized.

Show comment
Hide comment
@sebinsua

sebinsua Mar 6, 2018

@jonahbron As ava uses Babel 7 it should support TypeScript if you use @babel/plugin-transform-typescript. There are a few caveats though so it depends on whether you are using any of the unsupported features.

sebinsua commented Mar 6, 2018

@jonahbron As ava uses Babel 7 it should support TypeScript if you use @babel/plugin-transform-typescript. There are a few caveats though so it depends on whether you are using any of the unsupported features.

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Mar 6, 2018

Member

As ava uses Babel 7

To clarify, that's the 1.0 beta releases.

Architecturally we're in a pretty decent place to implement built-in TypeScript compilation. It's still a big chunk of work though. So… any volunteers? 😄

We can also start adding support for test file extensions that bypass the Babel pipeline, so that'd be a way to use AVA with the TS register hook. That has some performance issues of course, so it may not be right for some (or most) projects.

Member

novemberborn commented Mar 6, 2018

As ava uses Babel 7

To clarify, that's the 1.0 beta releases.

Architecturally we're in a pretty decent place to implement built-in TypeScript compilation. It's still a big chunk of work though. So… any volunteers? 😄

We can also start adding support for test file extensions that bypass the Babel pipeline, so that'd be a way to use AVA with the TS register hook. That has some performance issues of course, so it may not be right for some (or most) projects.

@shirtleton

This comment has been minimized.

Show comment
Hide comment
@shirtleton

shirtleton Apr 16, 2018

Any updates on Typescript support?

shirtleton commented Apr 16, 2018

Any updates on Typescript support?

@Jaden-Giordano

This comment has been minimized.

Show comment
Hide comment
@Jaden-Giordano

Jaden-Giordano Apr 16, 2018

Contributor

Hey @shirtleton I'm working on making it so you can configure ava to use file extensions like .jsx or .ts. It's almost done, were just adding tests and cleaning up a bit of the code written for it, so should be soon. Here is the PR for reference #1746 Thanks!

Contributor

Jaden-Giordano commented Apr 16, 2018

Hey @shirtleton I'm working on making it so you can configure ava to use file extensions like .jsx or .ts. It's almost done, were just adding tests and cleaning up a bit of the code written for it, so should be soon. Here is the PR for reference #1746 Thanks!

one19 added a commit to one19/qul that referenced this issue Apr 25, 2018

@ShinDarth

This comment has been minimized.

Show comment
Hide comment
@ShinDarth

ShinDarth Aug 19, 2018

Any news about this?

ShinDarth commented Aug 19, 2018

Any news about this?

@vladimiry

This comment has been minimized.

Show comment
Hide comment
@vladimiry

vladimiry Aug 19, 2018

@ShinDarth it's working with ts-node module installed and config shown here https://github.com/avajs/ava/blob/master/docs/recipes/typescript.md (first TS recipe)

vladimiry commented Aug 19, 2018

@ShinDarth it's working with ts-node module installed and config shown here https://github.com/avajs/ava/blob/master/docs/recipes/typescript.md (first TS recipe)

@novemberborn

This comment has been minimized.

Show comment
Hide comment
@novemberborn

novemberborn Aug 19, 2018

Member

Yes, AVA can now be configured to recognize the .ts file extension. With TypeScript 3 the build tooling has improved a lot, so I think we can make AVA compile a TypeScript project, without requiring ts-node.

I'd like to port some of my own projects to TypeScript so I'd really like to see improved TypeScript support in AVA. For now though my priority is getting the 1.0 release out.

If anybody would like to help out with this project please give me a shout.

Member

novemberborn commented Aug 19, 2018

Yes, AVA can now be configured to recognize the .ts file extension. With TypeScript 3 the build tooling has improved a lot, so I think we can make AVA compile a TypeScript project, without requiring ts-node.

I'd like to port some of my own projects to TypeScript so I'd really like to see improved TypeScript support in AVA. For now though my priority is getting the 1.0 release out.

If anybody would like to help out with this project please give me a shout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment