3 ms·

Yes, I don't think I was clear enough but I edited a lot of points out of my post as it was far too long! The biggest problems in any modern, large-scale JavaS

Yes, I don't think I was clear enough but I edited a lot of points out of my post as it was far too long! The biggest problems in any modern, large-scale JavaScript project are the build process and dependency management. If you are publishing a TypeScript library then it can be consumed either natively as TypeScript, or as ES5. If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. That doesn't negate the internal benefits to your library, but Flow is another option that is a better fit if you are mostly interested in going with the prevailing wind. After all, that was the author's central argument as to why you should choose TS over Flow, and IMO it is quite wrong.

Bahamut 11y ago
The article talks about TypeScript vs. Flow as well - TS has a lot more popularity than Flow currently, and it only looks like the gap is going to grow larger. Types also allows for auto-generation of docs that are guaranteed to reflect the current state of the code. For a library maintainer, a maintainer can just release an ES5 version of the library when publishing via npm - the user then gets the benefit of choosing between TS or ES5. It can also simultaneously be released as ES6 if desired. I should mention that it doesn't make sense for pre-existing libraries to migrate to TS (or anything) if it is already in JS and is a largely used library without a specific end goal that is to be achieved - the article is wrong about that, open source doesn't have infinite resources unfortunately.
Eridrus 11y ago
> If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. Unless you're making changes to a TS library, there should be no need to build it and you can just use existing the built js files from the library.

Bahamut 11y ago

The article talks about TypeScript vs. Flow as well - TS has a lot more popularity than Flow currently, and it only looks like the gap is going to grow larger. Types also allows for auto-generation of docs that are guaranteed to reflect the current state of the code. For a library maintainer, a maintainer can just release an ES5 version of the library when publishing via npm - the user then gets the benefit of choosing between TS or ES5. It can also simultaneously be released as ES6 if desired. I should mention that it doesn't make sense for pre-existing libraries to migrate to TS (or anything) if it is already in JS and is a largely used library without a specific end goal that is to be achieved - the article is wrong about that, open source doesn't have infinite resources unfortunately.

Eridrus 11y ago

> If it is being consumed as ES5 then your consumers lose most of the benefits of it being in TS. For them to consume it as native TS puts a fairly hefty constraint on their build process, namely that it must go through the TypeScript compiler. Unless you're making changes to a TS library, there should be no need to build it and you can just use existing the built js files from the library.