Add TypeScript support. Closes #1025

[hueniverse]

No description provided.

[devinivy]

Was finally able to give this a proper read. It looks good to me and I'm all for the functionality— thanks!

[kanongil]

It would be nice with better typescript integration, but I'm concerned about officially supporting it. The main issue is that the transpiling can introduce extra checks in the output, some of which can be impossible to reach using tests, causing coverage to fall. I don't know if there is a reasonable solution to this?

I would also like to see a test for how --typescript behaves when the dependency is missing, similar to

lab/test/runner.js

Line 1967 in 6533396

it('runs when typescript fails to load', async () => {

[hueniverse]

It would be nice with better typescript integration, but I'm concerned about officially supporting it. The main issue is that the transpiling can introduce extra checks in the output, some of which can be impossible to reach using tests, causing coverage to fall. I don't know if there is a reasonable solution to this?

We need to move to use v8 built-in coverage tooling to get proper coverage reports and get rid of the way we do it today. That said, it works pretty well. I haven't hit any actual issues with coverage so far. The additional code is pretty small and supporting it would be trivial. If limitations are found in the future, we can deal with them then or move support elsewhere as last resort.

[hueniverse]

I would also like to see a test for how --typescript behaves when the dependency is missing, similar to

No need since this is only in the cli, not the reporter so it will just fail as expected.

[kanongil]

It would be nice with better typescript integration, but I'm concerned about officially supporting it. The main issue is that the transpiling can introduce extra checks in the output, some of which can be impossible to reach using tests, causing coverage to fall. I don't know if there is a reasonable solution to this?

We need to move to use v8 built-in coverage tooling to get proper coverage reports and get rid of the way we do it today. That said, it works pretty well. I haven't hit any actual issues with coverage so far. The additional code is pretty small and supporting it would be trivial. If limitations are found in the future, we can deal with them then or move support elsewhere as last resort.

I'm talking the coverage tool when applied to .ts files through the transform. It will only see the resulting .js code, which can contain more statements than in the .ts code. Eg. the generated code for a declared enum has an untestable conditional code path, as discussed in #1002.