build: do not minify published code#547
Conversation
commit: |
There was a problem hiding this comment.
Pull request overview
This PR updates the tsdown build configuration so the published dist output is no longer minified, aligning the package output with the stated goal of improving debuggability and auditability for consumers.
Changes:
- Removed the
minifyconfiguration from thetsdownbuild config so output is not compressed/mangled during publishing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
The downsides are very little compared to the gains. The source maps are not generated during the build? |
|
I don't agree with that at all. Publishing developer tools as minified code is bad practice overall. Including source maps in the published package would increase the package size even more. I would not recommend that either. |
It depends on the code purpose. The API is compatible with browser to allow direct usage. So code minified can stay for browser for example. Since the code is transpiled, the debugging to the exact original code can only be achieved with a source maps file. Adding a source maps allow the debugging and keep the "tiny" expectation given the github org purpose.
The package size is not the issue here, the issue is the effective code file size that ends up loaded by the JS runtime and that is meant to stay tiny. The source maps are only loaded on demand per user request. |
|
My opinion: I'd prefer we do not turn source maps on as it is just a good way to bloat a package only a minority will ever want to debug. As for this change - as a library, I agree we shouldn't minify. For browsers, it does make some sense. Personally, I would just turn minification off assuming it doesn't make a huge difference to the size. I guess the important question: how much bigger is it? |
- ℹ dist/index.js 32.79 kB │ gzip: 13.51 kB
+ ℹ dist/index.js 46.22 kB │ gzip: 15.17 kB
ℹ dist/index.d.ts 22.93 kB │ gzip: 5.26 kB
- ℹ 2 files, total: 55.72 kB
+ ℹ 2 files, total: 69.15 kB |
I guess tsdown can be configured to minify a target (.min.js) and not the others. And the package.json export the right target for browser, ESM or CJS ? |
|
it means we'd have to ship two bundles, which is out of the question i think. so we really just need to decide one way or the other: minify or don't minify. @jerome-benoit the extra 10KB is acceptable to make the code debuggable without shipping sourcemaps i think. though the extra size is basically comments (which are not really useful since our DTS contains the same JSDoc). we could also use this tsdown config it seems: outputOptions: {
comments: false
},
minify: {
compress: true,
mangle: true,
codegen: {
removeWhitespace: false
}
},so we strip comments and keep whitespace. then its 38KB vs 32KB iirc |
I think this decision should be based on Tinybench's users. 97.7% of Tinybench users are using it via Vitest. Maybe the remaining users are using it directly in browser. (Actually I'm quite sure most, maybe even 95% of that, is not even using Tinybench when they install Vitest, it's just transitive dependency for them) 
|
Published code should not be minified. It has many downsides, like making debugging more difficult, making it easier to hide malicious code there, etc. End users can minify it if they are bundling Tinybench anywhere.