[Docs] What is the practical difference of using @ava/typescript? Should I expect automagic source mapping?

[papb]

Note: I have phrased this issue mostly as a question, but please look at it as a request for documentation improvement - I looked around but didn't find anything on this.

---

My @papb/zip module is written in TypeScript and I currently test it with ava, but without @ava/typescript.

Today I tried to configure @ava/typescript on it. However, although it works, I could not see any practical difference. I thought perhaps source mapping would work automagically, but I still get outputs based on the compiled file.

For example, adding a simple failing test as follows:

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

test('Tests not ready...', t => {
	t.fail();
});

Still yields:

Note the presence of ava_1.default.

This was the only thing I was expecting to change. If this still works as before, what is the practical advantage of starting to use @ava/typescript?

[novemberborn]

You can run specific test files based on their source location, rather than the build output:

npx ava test/test.ts

Which is quite nice if you have multiple test files.

#12 will let AVA compile your sources before running tests.

With regards to source maps, it's probably best to install source-map-support and then require source-map-support/register through AVA's require option.

(I'm closing this issue for housekeeping purposes, but let's keep the conversation going.)

[papb]

Thanks for the fast response, sorry to take long to reply. What you said clarified it to me. Also thank you very much for the tip on source maps! Is this documented somewhere?

[novemberborn]

thank you very much for the tip on source maps! Is this documented somewhere?

@papb I don't think so… I've opened #20. Perhaps you'd be interested in doing a PR for that? 😄

[jonsadka]

This was helpful and probably worthy of adding to the README.md :)

[novemberborn]

This was helpful and probably worthy of adding to the README.md :)

@jonsadka Yes, see #20.