3 ms·
> 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 n
by rezonant 2y ago
> 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 2y agoYou 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 2y agoYes, 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 2y agoThat can be nice, but do keep in mind that shipping more files leads to a larger tarball downloaded from npm.
- rezonant 2y agoOf 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.