Post

Rob Palmer
@robpalmer.bsky.social

I'm very impressed with the collaboration we've seen from TypeScript to make Node integration a success. It is a team effort with all participants leaning in. Extension rewriting in TS 5.7 is the first treat. This was directly motivated by the Node use-case. And there's more to come! 💙

Rob Palmer@robpalmer.bsky.social

TypeScript 5.7 is released 🎉 🔶 ES2024 library types 🔷 Checker: Never-initialized variables 🔷 Checker: Stricter JSON imports 🔷 Emit: Extension rewriting (*.ts to *.js) 🔷 DTS: Computed methods 🔷 IDE: Better tsconfig discovery 🔷 Perf: Code Caching ⚡️ 2.5x faster startup

Jacob
@ebey.dev

Honestly the only change to TS that has made me cringe and think through the use-cases. I'm *very* torn to put it safely.

Jacob
@ebey.dev

This is a move that makes it feel like TS is it's own language when it reality it's a superset of JS designed as a superset to work with types stripped off the syntax. Imports are no longer required to be valid for the environment you are authoring.

Jacob
@ebey.dev

If this is the direction it's taking, either knowingly or accidentally, another TS / Flow will emerge. I don't want it to, but watch it happen.

Florens Verschelde
@fvsch.com

Lack of extension rewriting meant I had to take Rollup to emit .js files with correct imports, because tsc would output .js files that imported non-existing .ts files. As a user of tsc, it was a stupid limitation. (I understand it was not actually stupid originally. Still stupid in that use case.)

0 reposts0 likes

Florens Verschelde
@fvsch.com

Use case was a library authored with valid ESM import specifiers, i.e. `import foo from './foo.ts'` instead of `from './foo'`. (There is no 'foo' or 'foo.js' file in that folder.) Solving this without changing the imports to invalid ESM (not my lib, not my choice) was a STRUGGLE.