This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/egoist/tsup/5JH35zdH8ZCxW8ySKzW7rdPcdazQ
✅ Preview: https://tsup-git-fork-eric-burel-patch-1-egoist.vercel.app

🎉 This PR is included in version 5.12.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

They should not be included in a published NPM package and should not be confused with sourcemaps.

Hello, I was reading the tsup docs today, and I came across this, but I do not think that this advice is correct.

In fact, I think the advice is exactly opposite - every npm library should include declaration maps, since they are necessary in order for F12 to work properly.

In other words:

• Say that I have a library foo that is written in TypeScript.
• I publish it to npm.
• Alice wants to use my library, so she does npm install --save foo.
• Alice imports a helper function from my library, useFoo.
• Alice wonders what useFoo actually does, so inside VSCode, she presses F12 on it (i.e. "Go to Definition") so that she can read the source code.
• However, doing this warps to the ugly, compiled JavaScript code in the file of "./node_modules/foo/dist/functions/useFoo.js".

This is a bug, because pressing F12 should warp to the actual TypeScript source code (e.g. "./node_modules/foo/src/functions/useFoo.ts"). But fixing this is trivial: all we have to do is set the declarationMap compiler option to true, and then make sure that both "dist" and "src" are included in the "files" array inside of the project's "package.json" file.

I understand that currently, tsup does not support declaration maps, but the docs should at least be explaining correctly what declaration maps are for.

@eric-burel @egoist Am I missing some key context? Do you want me to do a PR to rewrite this?

@Zamiell I haven't worked in this area recently but I'd say it's a design choice for the package owner. Compiled JS/TS indeed have the default of losing the "white box" model of script languages. Actually even in a compiled Golang app, the "source is the documentation".
But the thing is that in Golang for instance, only your application recompiles the code. So, Golang package actually deliver the plain sources (I might super over simplify here but you get the point).
Weirdly enough, this is not the case in JS, where we do "double bundle" all the time: you bundle a TS package that I use in my Next.js app that will also rebundle it. This is often mandatory because of technical quirks like not using the same TS version, and very annoying.

In the Devographics codebase, our shared packages are TypeScript only so you can indeed jump to source: https://github.com/Devographics/Monorepo (see "shared" folders and how we use "@devographics/" packages)

But they are not published so we have full control about the build environment they end up into.

Maybe outputting TS code to clean ESM rather than ugly minified JS could be a solution. To answer your question more directly: I am not sure that including the TS sources is the way, maybe compiling to a human readable code would be better suited.

I also program in Golang, and the solution I outlined in my previous reply makes TypeScript work identical to Golang in this respect, which is great.

To answer your question more directly: I am not sure that including the TS sources is the way, maybe compiling to a human readable code would be better suited.

Why though? What is the actual disadvantage of including the src directory in your library bundle? It obviously increases the size of the dependency, but it would be by some trivial amount. And the dependency size cost is only incurred when first cloning a project and installing the deps, so its one-time. Meaning that the src directory would only be present for developers who are working on the code, it would never make its way into apps that are created with a tree-shaking bundler. Including src strikes me as having virtually no downside.