issue when configuring lib

[KiaraGrouwstra]

const options: ts.CompilerOptions = { lib: ['es2015'] } -> boom

typecheck.ts:108
  let { line } = diagnostic.file.getLineAndCharacterOfPosition(diagnostic.start);
        ^
TypeError: Cannot read property 'getLineAndCharacterOfPosition' of undefined

Essentially all I was trying to do was solving a bunch of Cannot find name 'Promise' errors.

[danvk]

Can you say a little more about how you get this error? I can't reproduce.

$ cat issue2.ts
const options: ts.CompilerOptions = { lib: ['es2015'] }

$ ts-node typecheck.ts issue2.ts
issue2.ts:1: Unexpected error
  Cannot find namespace 'ts'.
Successes: 0
Failures: 1

[KiaraGrouwstra]

What seems to happen for me is that the diagnostic ends up with empty info:

{ file: undefined,
  start: undefined,
  length: undefined,
  messageText: 'Cannot find global type \'Array\'.',
  category: 1,
  code: 2318 }

Going by that, it seems the standard library is no longer loaded, see here. This also happens if lib gets an empty array, implying as long as it's specified it would need to include everything necessary. This begs the question why behavior on my end appears different from that on yours though...

At that point you'd wonder, why touch lib at all? So the thing was, without touching it I'm already getting Cannot find name 'Promise'. -- hence my reflex to try and load the ES6 type library. Using lib: ['lib'] I've managed to got back to point 0, but I haven't really managed to advance beyond that.

I'm not sure a PR for CI would help, as my change was literally just that... so I'm not sure I can provide something that'd reproduce my situation on your end. :(

[danvk]

@tycho01 I published an npm package; you should be able to add typings-checker to your devDependencies and run it as typings-checker test.ts in your project (as opposed to copying the source).

typings-checker doesn't read your tsconfig.json. I added a TODO for this.

Have you been able to get this working for types/npm-ramda? It would be great to get you guys as users. I'd also be happy to add you as contributors to this repo if you'd like to hack on it yourself.

[KiaraGrouwstra]

Heck, this is just solving the greatest problem I had for the ramda typings (actually knowing what the hell we're doing instead of being pretty much clueless w.r.t. whether a commit makes things better or worse), so I'm pretty thankful for your efforts here!

I'll swap out the copy to your NPM package tomorrow. :) I'm not sure I have solid ideas on how to improve the checker yet, but when I do I'll gladly make a PR! To be honest I should probably just retry my attempt here in a different environment hoping that'd work better, but yeah.

[danvk]

Cool, glad to hear it's working for you! I'd really like to get DT using this, or at least something like it. Low-quality type definitions are one of my biggest sources of frustration with TS. https://github.com/DefinitelyTyped/DefinitelyTyped/issues/1572#issuecomment-272571498

[KiaraGrouwstra]

Just thought of something: so I'm currently logging the output into git to allow diff checking. Line numbers are a bit unfortunate there since it might clog the diffs with noise. I'll try and see if I can add a mode just showing the line content instead.

[danvk]

@tycho01 I just released 1.1.0, which lets you make inline type assertions:

mapObject({a: 1, b: 2}, (
  val,  // $ExpectType number
  key,  // $ExpectType "a" | "b"
  c,  // $ExpectType { a: number; b: number; }
) => '' + val);

I expect this sort of thing will be really helpful for the rambda typings.

[KiaraGrouwstra]

Yeah, I hear you. When I tried checking the Lodash type definitions hoping they'd help me for Ramda, I for the most part ended up disappointed with the type inference they offered (-> not that much in terms of generics, largely rudimentary signatures to check parameter inputs).

Nitpick: I've gotta say it's definitely picky, to the extent of caring about parameter names. Also saw errors in the vein of expected string, inferred "foo". Still trying to figure out whether I feel it's too picky, but well, if anything erring in the direction of picky was kind of the point here I guess.

[KiaraGrouwstra]

Looks like I'm behind by one reaction. Thanks for the inline addition!