I used the template of the Ember.js RFC to document this issue. I think it is a good template to adress the main concerns about a bigger change. For details about their RFC process you can visit their github repo: https://github.com/emberjs/rfcs
I wanted to move all the TypeScript discussions into one single place, because right now all the pros and cons about TypeScript are scattred around several issues, threads, pull requests and discussions. This makes it very hard to follow and I think there won’t be any significant progress if we do not focus. Also I think there is a lot of traction concerning three.js and TypeScript as seen lately in #11552
Since TypeScript becomes more and more popular in the frontend community we could start thinking about adoption. Also if you compare the weekly downloads of
@types/three and the
three package on npm it seems that a lot of people use Three.js already with TypeScript. For the time frame 2019-01-01 to 2019-01-07 it was 56414 downloads of
three and 40588 for
@types/three (for more details see: https://www.npmjs.com/package/@types/three and https://www.npmjs.com/package/three). Furthermore there is already a lot of work done spread across several projects and repositories. Therefore it would be nice to join forces and maintain the TypeScript stuff in one place.
Some of pros I see are:
- possibility to improve developer experience, also for new contributors and for users of the Three library
- types could help to explorer the api of the Three library and they could help to develop with less need to read the docs
- no out dated
- room for future transpile optimizations (for example things like tsickle is doing right, I think there will be more tools like this in future). Also experimental tools like AssemblyScript could become an option for certain very performance critic parts of the source code
- types could help to improve code quality
- possibility to use new features of the ECMAScript standard and transpile the source to different ECMAScript versions
- when done right it makes no difference for the users of the Three library if the source code is maintained in TS or JS
- with the compiler flag
declarationDirwe are able to generate the
d.tsfiles from our source code so all typings are always up to date
tsconfig.json and setup all the TypeScript-compiler settings to our needs. Maybe we should add
tslint as well (there is also a rollup plugin for that, it’s called rollup-plugin-tslint). After the build works we could incorporate the typings done in
@types/three and other projects like three.ts.
How we teach this
The build pipeline becomes more complicated and more dependencies are added. Furthermore I’m not sure how easy it is to migrate the test suite and the test runner. Also the entry barrier for new contributors (not for users of the library) could become higher since they need to know TypeScript. Very generic code can become very verbose when adding types. With TypeScript we are a little bit more away of “the platform” since there is a transpile step inbetween and we are not in total control of transpilation (of course we could write our own transforms but this is very tedious)
@types/three. For all the users of Three.js with TypeScript this would mean that they need to rely on an unofficial typing of Three.
- Do we really want this?
- When to start (right now or after ES6 finalization)?
- How to start? Should we start at first only with
d.tsfiles or jump fully into TypeScript?
- Who could do this or let me phrase it differently, who is motivated to start this?