`tsc` is extremely slow to transpile TypeScript sources into JavaScript. It's invaluable for typechecking, but for transpilation there are much better solutions like SWC or tsup [1] (which nicely wraps esbuild and Rollup).
TypeScript NPM Packages Done Right
21–30 of 81 posts
Re: TypeScript NPM Packages Done Right
#22See also https://publint.dev/
TIL that types should be listed first in the export map thanks to that tool. I don't think it bothered anyone consuming my packages, but better be spec compliant and update them all. Thanks for sharing!
Re: TypeScript NPM Packages Done Right
#23I'm developing a npm package with just plain javascript modules. No more JS fatigue. I won't ever go back to TypeScript and JS compilers, modern JavaScript is capable enough to stop all this madness.
Re: TypeScript NPM Packages Done Right
#24`tsc` is extremely slow to transpile TypeScript sources into JavaScript. It's invaluable for typechecking, but for transpilation there are much better solutions like SWC or tsup [1] (which nicely wraps esbuild and Rollup). [1] https://tsup.egoist.dev/
> much better solutions like SWC
Which doesn't support const enum correctly and god knows what else without erroring.
Re: TypeScript NPM Packages Done Right
#25`tsc` is extremely slow to transpile TypeScript sources into JavaScript. It's invaluable for typechecking, but for transpilation there are much better solutions like SWC or tsup [1] (which nicely wraps esbuild and Rollup). [1] https://tsup.egoist.dev/
> `tsc` is extremely slow to transpile TypeScript sources into JavaScript
That’s because its main job is not transpiling to JS, but as a compiler it actually checks the correctness of the code, which is probably the main reason typescript exists in the first place.
You can actually run tsc without emitting JS at all in particular configurations.
Re: TypeScript NPM Packages Done Right
#26Earlier quoted context omitted.
If you're using TypeScript, you have a build step anyway, so you can easily use ESM.
Remember we’re using Node. I don’t think TypeScript compiler supports importing ESM into CommonJS files. Basically we will have to move the library to ESM and then use a bundler like esbuild to compile it to CJS as well for compatibility. It’s a mess
> It’s a mess
I think everyone agrees about this.
What people can’t agree about is how to fix it.
Re: TypeScript NPM Packages Done Right
#27`tsc` is extremely slow to transpile TypeScript sources into JavaScript. It's invaluable for typechecking, but for transpilation there are much better solutions like SWC or tsup [1] (which nicely wraps esbuild and Rollup). [1] https://tsup.egoist.dev/
> `tsc` is extremely slow to transpile TypeScript sources into JavaScript That’s because its main job is not transpiling to JS, but as a compiler it actually checks the correctness of the code, which is probably the main reason typescript exists in the first place. You can actually run tsc without emitting JS at all in particular configurations.
I know this is a "me" thing, but I've come to the point of view that making bits in a different order (eg: classic "compilation" of one language into another) is a very useful side effect of compilers. My main love of them now is as a complete suite of tests with "100%" (some will argue this) code coverage of types, in the languages where that matters. You called functions with what you thought you did, you're getting back what you think you are, you're doing operations on things that actually support them, etc.
Re: TypeScript NPM Packages Done Right
#28"module": "commonjs", Nope.
Anecdotally, ESM has been an absolute nightmare. Packages that aren’t compatible without code changes, having to add extensions to every single import unless we specify a flag (that is now deprecated), challenges with import maps and module resolution, the list goes on.
So we just use CommonJS with project references and call it a day. Everything works and we don’t need to change any of our code. The way ESM was introduced into Node has been the dumbest decision. And they’re doubling down on it. Excited for Bun to be compatible with my project so that I never have to deal with any of this again.
Re: TypeScript NPM Packages Done Right
#29Also, the default target configuration is "es2016," and modern browsers only support up to "es2015." I had to recheck this was indeed an article from 2023, because this part surprised me greatly. To my understanding, es2016 only added Array.prototype.includes, the exponentiation operator (**), and preventing generator functions from being constructed. Even the slowest adopters already had these in 2017. Is the author…
No idea. Matt Pocock has a much better cheat sheet for tsconfig configurations and his is set as es2022. https://twitter.com/mattpocockuk/status/1701619240686485799
Link to full cheatsheet: https://www.totaltypescript.com/tsconfig-cheat-sheet
Re: TypeScript NPM Packages Done Right
#30Also, the default target configuration is "es2016," and modern browsers only support up to "es2015." I had to recheck this was indeed an article from 2023, because this part surprised me greatly. To my understanding, es2016 only added Array.prototype.includes, the exponentiation operator (**), and preventing generator functions from being constructed. Even the slowest adopters already had these in 2017. Is the author…
Yeah, I stopped reading after that. A browser that only "supports up to es2015" is not a "modern browser".