Skip to content

Latest commit

 

History

History
58 lines (42 loc) · 2.24 KB

README.md

File metadata and controls

58 lines (42 loc) · 2.24 KB

This is not maintained! Check out dtslint and tsd.


typings-checker CircleCI

The tests in DefinitelyTyped verify that correct code type checks. But this is an easy bar to meet: giving a module an any type is sufficient to make its tests type check.

It's just as important that incorrect code not typecheck. There isn't any way to test for this in DT right now. This repo provides a proof of concept for how this could be added. It's modeleled after the way FlowTyped handles things.

Here's what a test for _.find might look like:

_.find([1, 2, 3], x => x * 1 == 3);  // (this is just expected to type check)
// $ExpectError Operator '==' cannot be applied to types 'number' and 'string'.
_.find([1, 2, 3], x => x == 'a');
// $ExpectType number
_.find([1, 2, 3], 1);
// $ExpectError Property 'y' does not exist on type '{ x: number; }'.
_.find([{x:1}, {x:2}, {x:3}], v => v.y == 3);
// $ExpectType { x: number; }
_.find([{x:1}, {x:2}, {x:3}], v => v.x == 3);

Code is expected to type check unless an $ExpectError directive is used. In this case, an error is required (lack of an error from TypeScript is a test failure).

An $ExpectType directive tests the type of the expression on the next line. This prevents unexpected any or {} types from creeping in.

Usage

npm install -g typings-checker
typings-checker --project tsconfig.json your-test.ts your-second-test.ts

Options

--project
  Path to the relevant tsconfig.json file

--allow-expect-error
  Enables $ExpectError assertions. These can help pin down behavior but they
  also prevent tsc from running over your assertions. Disabled by default.

Development

$ npm install -g yarn ts-node
$ yarn
$ ts-node src/index.ts sample.ts
Successes: 6
Failures: 0