Many of the projects I’ve seen that use this approach end up having more bugs and a long list of PRs saying “the types don’t match the output.” As compared to the libraries that use TypeScript inside and out, they don’t have to worry as much about the public interface being accurate. I feel like as a library creator, it’s imperative to uphold the contract at the boundaries of your library.
And sorry for not citing evidence. There’s the whole Airbnb refactor that cited something like 60% bug reduction by using TS.
I wholeheartedly agree. I ran into these type mismatch problems a lot.
However, this article isn't about telling you that you should use this technique. It's about making people know that this an option that they can consider. There are constraints when you simply can't have TS compiler in the toolchain(I had on one such project, and there was no other way around it).
I do not say this approach is superior. It is not. It's simply one such approach in the vast world of JS programming.
Well, now that Babel can do Typescript transpiration, there really aren’t many constraints that prevent the use of Typescript. I’d be interested to hear others.
Sure, I hadn’t thought about pushing the transpiration responsibilities down the consumer of the library.
To be fair, the typescript compiler can turn off a lot of the transpiration stuff if you change the target in tsconfig.JSON to ESNext or ES2020. That means you can get the advantages of (full) type checking without the noise since the compiler assumes the browser knows about things like Object.entries and the spread operator.
Many of the projects I’ve seen that use this approach end up having more bugs and a long list of PRs saying “the types don’t match the output.” As compared to the libraries that use TypeScript inside and out, they don’t have to worry as much about the public interface being accurate. I feel like as a library creator, it’s imperative to uphold the contract at the boundaries of your library.
And sorry for not citing evidence. There’s the whole Airbnb refactor that cited something like 60% bug reduction by using TS.
I wholeheartedly agree. I ran into these type mismatch problems a lot.
However, this article isn't about telling you that you should use this technique. It's about making people know that this an option that they can consider. There are constraints when you simply can't have TS compiler in the toolchain(I had on one such project, and there was no other way around it).
I do not say this approach is superior. It is not. It's simply one such approach in the vast world of JS programming.
Well, now that Babel can do Typescript transpiration, there really aren’t many constraints that prevent the use of Typescript. I’d be interested to hear others.
The constraint wasn't not having TypeScript, but not having any compile/watch step at all, which is the why behind this article.
Sure, I hadn’t thought about pushing the transpiration responsibilities down the consumer of the library.
To be fair, the typescript compiler can turn off a lot of the transpiration stuff if you change the target in tsconfig.JSON to ESNext or ES2020. That means you can get the advantages of (full) type checking without the noise since the compiler assumes the browser knows about things like Object.entries and the spread operator.
typescriptlang.org/tsconfig#target