TypeScript support

I am curious if it’s planned? From my experience, it is so much easier to have a project written in Typescript instead of creating ad-hoc typings and maintaining those (same way as react-apollo does it).

It’s not a problem to use .mjs, the TypeScript is able to emit full ESM module, although it will be with .js extension so there would need to be an extra step of renaming those, but that should be easy.

[danielkcz]

Thanks for your detailed explanation, at least now I know I can safely ignore this project 😉

I am not going to try to convince you, but I think you are kinda biased against TypeScript right now, so I will just leave a few pointers. I would like to you invite to read my recent article about TypeScript.

1. TypeScript adoption is growing and with its ability to infer a lot of things, you might not even spot a difference.
2. Pretty much same as 1) With eg. VSCode everything works out of the box. And GH already has syntax highlight for TypeScript, no problem there.
3. Of course, there is some extra effort needed, but often it gives you a lot of benefits back.
4. I am not sure why is Apollo struggling with that, haven’t investigated, but TypeScript is able to emit ESM module (without require) just fine.
5. Do you realize that if adoption of this module will grow, somebody will create separate typings to it anyway? There are people who like the convenience of typed code and they would rather “chase the end of the rainbow” or not to use the module at all.
6. This is definitely just a bias without any proof.
7. There is my response to the article about JSDoc comparison.. The biggest hurdle with JSDoc is that it’s easy to get unmaintained and misleading. You are also missing out on a lot of useful tools like automated refactoring that comes with VSCode.
8. Are you sure about that? 😄 I would say it’s quite opposite way. For example I can use <></> (fragments) in TypeScript right now instead of using some beta of Babel which lacks general support in other areas. I haven’t found a single feature that Babel would have and TypeScript would not. Well, except decorators, but given those are still lacking proper spec, I don’t care about that.

Frankly, I couldn’t work anymore without TypyScript telling me the result of my queries or what variables are required for a mutation. You can never achieve that level of conveniece with JSDoc.

[jaydenseric]

Thanks for the suggestion, but not being typed is an intentional differentiation from Relay and Apollo. We won’t use TypeScript here for a few reasons:

1. It limits the ability to contribute to a very small group who are familiar with TypeScript.
2. It makes the source code illegible to most people. They might not understand it and they might not have TypeScript syntax highlighting configured. Lots of consumers like to read the source code just to understand it, without the intention of modifying anything.
3. For people willing to learn to make a contribution, fiddling with types can make what would have been a quick PR a complex effort. I experienced this a lot when I began contributing to Apollo.
4. TypeScript is not friendly to .mjs with several issues. For example, it outputs invalid ESM by mixing in require. Apollo has given up trying for now.
5. “type safety” is an illusion when the typed code you write is dwarfed by the untyped code bundled from node_modules. DefinitelyTyped and flow-typed are the worst idea ever: Third parties chasing the end of the rainbow documenting code isolated from the source. Importing a dependency and using it is no longer a simple exercise. Neither is updating dependencies.
6. Trying to hack JS into a cumbersome, strictly typed language prevents using elegant and useful patterns that take advantage of the flexible nature of JS for minimal bundle size.
7. Unlike TypeScript types, radically updating JSDoc (renaming types, etc.) is not a breaking change.
8. Being able to avoid the TypeScript compiler with Babel v7 is a big step in the right direction, but it’s still early days. The TypeScript compiler is far behind the evolution of Babel regarding transpiling for the environment a la @babel/preset-env. Chaining a second Babel compile after TS is pretty inefficient and it can get in the way of fine-grained optimizations via Babel plugin config.

My intention is to only reduce the code we have now, and never exceed around 1-2 KB source. JSDoc is manageable at this scale and documentation.js is working well to keep the API in the readme up to date.

Where possible I strip transpilation from projects once Node.js and browsers are able to handle the APIs and language features used natively. Once IE11 dies off a lot will change fast. Everyone should be working towards a native, standards based web and I don’t believe in TypeScript as a permanent fixture.