[WIP] chore: convert to TS

[JoviDeCroock]

So as suggested by @benjamn I started on the conversion to TS, this has proven to be non-trivial, so I'm already putting it out there so anyone passing by can see and give their two cents about it

#234 (comment) --> ref to comment about conversion to TS

[JoviDeCroock]

Hmm, the tests seem like something else... This feels really weird since we're working with a .default AND a module.exports. The default import is working but the other isn't... Some parts of this code feel really weird

[JoviDeCroock]

In the tests two issues are still open

V0.11: This test is not being executed in master atm so I did not migrate it to TypeScript
Normal tests: unique fragments › ignores duplicate fragments from second-level imports when using the webpack loader, the import for that imaginary .graphql file is not working anymore. It fails on eval

The // TODO comments in src/index.ts need a review since I don't have enough knowledge about the underlying aspect myself.

Also we need to find a way to test with these different versions but then with our new jest tests.

Sorry for leaving this much open but it's quite hard to "choose" an infrastructure.

I'll probably add test to the CI when the changes are approved

[jnwng]

V0.11: This test is not being executed in master atm so I did not migrate it to TypeScript

tests for graphql@0.11 get executed via test-all-versions (see here)

overall, i think translating this library to typescript is a useful effort. however. i would want to ensure that tests still pass — we don't want to drop any support unnecessarily, plus we'd expect the same behavior here.

additionally, i don't feel comfortable merging the parts that are "unknown" in TypeScript-land, so it'd be valuable to have someone review this who might have the answers we need.

in the pursuit of moving this forward, can we break this down into smaller pieces to get pieces of it through, first? perhaps splitting this into 1) infrastructural changes (e.g., the typescript toolchain) 2) typescript interfaces and 3) tests? that might allow us to have a more focused look at the individual parts of the library that are being ported.

thoughts?

[JoviDeCroock]

@jnwng
I'm up to split the PR up into multiple parts, I'll start off by making an infrastructure PR conforming to apollo-client. Then make multiple others that will be targetted at the infrastructure PR, does this sound okay for you?

Steps:

1. add TS infrastructure
2. convert the source to .ts
3. update way of building
4. retarget loader.js
5. tests
6. Remove obsolete dependencies

Also when I look at the travis CI jobs (ex: https://travis-ci.org/apollographql/graphql-tag/jobs/476452576) I see that 0.11 fails, that's why I thought that.