[pzmarzly]

From what I understand, the author is persuading library authors to stop compiling TS->JS, and instead ship your TS files to the users over npm. I like the idea of it, but will it actually work in practice? What if some dependency only compiles with some version of tsc? What if it needs different tsconfig-s?

[rezonant]

> but will it actually work in practice?

No. It seems like they are assuming the user is using JSR, which handles generation of JS and d.ts for you. But then none of this would even be a problem.

The NPM registry doesn't do any of that. You could absolutely publish only .ts files to NPM and then use a post install script to generate JS and d.ts files, but that is a pretty terrible idea. Even if the process is super fast, it's still an operation done potentially millions of times, versus an operation which can happen once at publish time. You could also assume the user will have their own mechanism for compiling TS or consuming TS directly, but this is even worse.

[afavour]

You can specify different exports based on environment in the package.json so you could ship TS files… alongside JS files, so it feels a little redundant.

[rezonant]

Yes, I recommend shipping TS source alongside compiled JS+d.ts even if you don't support a TS native environment, because you then have the potential of a source mapped debugging experience within that library (though currently doing that is a bit painful in some debuggers).

[stevenpetryk]

That can be nice, but do keep in mind that shipping more files leads to a larger tarball downloaded from npm.

[rezonant]

Of course. A few more kilobytes is a good tradeoff for debuggability and the ability to read the original code during development. Web apps that get bundled won't include it, ESM web apps won't request them, and if a server side application is sensitive to deployment size, it's trivial to remove source files from all dependencies during build. As an application developer I'd much rather an upstream package provide it and let me strip it out than the opposite.

[mhagemeister]

Author here. I should've worded that better. The recommendation is not to stop compiling TS->JS for npm users. The whole npm ecosystem is built around the assumption that you ship JS and doing anything else would break it.

In Deno (disclaimer: I work for Deno), which supports running TS natively, packaging outside of npm has always worked by shipping the TS files directly. Transpiling them down to JS files is only something you ever had to do when publishing on npm.

So far the problem that a dependency only compiles with a certain version of tsc hasn't popped up since Deno was launched. But that may have been because Deno always ships with latest TS and Deno users don't hesitate to update as we haven't done any breaking changes so far.