Setup tsdown #381
Setup tsdown #381
Conversation
WalkthroughThis pull request migrates the project's build toolchain from Rollup to tsdown. The package.json is updated with version 1.5.3-beta.0, restructured export paths to use dist/cjs and dist/esm subdirectories instead of dist root, changed the build script from rollup to tsdown, and updated development dependencies by removing rollup and @rollup/plugin-typescript while adding tsdown. The rollup.config.mjs is deleted and replaced with tsdown.config.mjs, which defines two build configurations for ESM and CJS formats. The tsconfig.json is also removed, presumably delegating TypeScript configuration to tsdown. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
vio
force-pushed
the
tsdown
branch
2 times, most recently
from
06444ae to
010440e
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
tsdown.config.mjs (1)
12-12: Consider disabling minification for library code.Minifying library code can make debugging more difficult for consumers, as it obfuscates stack traces and makes source inspection harder even with source maps. Libraries typically ship unminified code and let consuming applications decide whether to minify.
Apply this diff to disable minification:
format: 'esm', hash: false, - minify: true, + minify: false, sourcemap: true, }, { outDir: 'dist/cjs', entry: { index: './src/index.ts', extract: './src/extract.ts', }, format: 'cjs', hash: false, - minify: true, + minify: false, sourcemap: true, },Also applies to: 23-23
package.json (1)
77-77: Confirm tsdown ^0.15.12 dependency management strategy.The latest stable release is v0.15.12 (released Oct 29, 2025), and the project is under active development with frequent releases and breaking changes; users should expect API/config migrations and occasional regressions. The original concern is valid—the community recommends testing upgrades in CI or a branch before adopting in production.
Consider implementing one of the suggested approaches:
- Pin to a specific version (e.g.,
"tsdown": "0.15.12") to avoid unexpected breaking changes during active development, or- Establish a monitoring and testing process in your CI/CD pipeline before upgrading to new tsdown releases.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
package.json(3 hunks)rollup.config.mjs(0 hunks)tsconfig.json(0 hunks)tsdown.config.mjs(1 hunks)
💤 Files with no reviewable changes (2)
- rollup.config.mjs
- tsconfig.json
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Socket Security: Pull Request Alerts
🔇 Additional comments (2)
package.json (1)
4-4: Beta version is appropriate for this migration.The version bump to 1.5.3-beta.0 correctly signals that this is a pre-release version with significant build tooling changes, allowing early testing before a stable release.
tsdown.config.mjs (1)
1-26: Now let me verify tsdown's behavior regarding automatic type declaration generation:No action required—tsdown automatically generates type declarations.
Tsdown automatically enables declaration file generation when package.json contains a types or typings field. The package.json already specifies both
"typings": "dist/esm/index.d.ts"and"types"entries in exports, so declaration file generation will be enabled by default. With TypeScript (5.9.3) installed as a devDependency, the configuration is complete and requires no changes. The absence of an explicitdtsoption or tsconfig.json is not a problem.Likely an incorrect or invalid review comment.
| "main": "dist/cjs/index.js", | ||
| "module": "dist/esm/index.mjs", | ||
| "typings": "dist/esm/index.d.ts", | ||
| "files": [ | ||
| "dist" | ||
| ], | ||
| "exports": { | ||
| ".": { | ||
| "types": "./dist/index.d.ts", | ||
| "import": "./dist/index.mjs", | ||
| "require": "./dist/index.cjs" | ||
| "types": "./dist/esm/index.d.ts", | ||
| "import": "./dist/esm/index.mjs", | ||
| "require": "./dist/cjs/index.js" | ||
| }, | ||
| "./extract": { | ||
| "types": "./dist/extract.d.ts", | ||
| "import": "./dist/extract.mjs", | ||
| "require": "./dist/extract.cjs" | ||
| "types": "./dist/esm/extract.d.ts", | ||
| "import": "./dist/esm/extract.mjs", | ||
| "require": "./dist/cjs/extract.js" |
There was a problem hiding this comment.
🧩 Analysis chain
Verify output file extensions match tsdown's defaults.
The package.json expects specific file extensions:
- ESM outputs:
.mjs(lines 28, 36, 41) - CJS outputs:
.js(lines 27, 37, 42)
Please confirm that tsdown generates these exact extensions by default. Some build tools require explicit outExtension configuration to control output file extensions.
🏁 Script executed:
#!/bin/bash
# Build and verify the actual output file extensions
npm run build
echo "=== ESM output files ==="
ls -la dist/esm/
echo "=== CJS output files ==="
ls -la dist/cjs/
# Verify the specific files referenced in package.json
echo "=== Verifying package.json entry points ==="
ls -la dist/cjs/index.js dist/esm/index.mjs dist/cjs/extract.js dist/esm/extract.mjs 2>&1Length of output: 550
I need to investigate the tsdown configuration and its default behavior since the build failed in the sandbox. Let me check the codebase for tsdown configuration and search for information about tsdown's defaults.
Now I need to check the actual package.json and tsdown configuration in the repository:
I need to check the actual codebase for the package.json configuration and tsdown setup:
---
🏁 Script executed:
```shell
#!/bin/bash
# Check the beginning of package.json to find the "type" field
head -30 package.json | cat -n
# Look for tsdown configuration file
fd -t f 'tsdown.config' -e ts -e js
Length of output: 901
---
🏁 Script executed:
```shell
#!/bin/bash
# Search entire package.json for "type" field
grep -n '"type"' package.json
# Check for any config files that might have tsdown settings
fd -t f '(tsconfig|tsdown)' -e json -e ts -e js -e mjs -e cjs
# Also check the full length of package.json
wc -l package.json
Length of output: 54
---
🏁 Script executed:
```shell
#!/bin/bash
# Display the tsdown configuration
cat tsdown.config.mjs
# Search package.json specifically for module package type fields
rg -n '"type"\s*:\s*("|module|commonjs)' package.json
Length of output: 482
Add "type": "module" to package.json to ensure tsdown generates correct output file extensions.
The current tsdown.config.mjs lacks fixedExtension configuration, which means the output file extensions depend on the package type, and when not fixed, the extension will always be .cjs or .mjs, otherwise it will depend on the package type. Since package.json has no "type" field, Node.js defaults to "type": "commonjs", which causes tsdown to output .js files for both ESM and CJS builds instead of the expected .mjs for ESM.
To resolve this and match the package.json entries (lines 27-42), add "type": "module" near the top of package.json. This will ensure tsdown generates .mjs for ESM and .js for CJS by default.
🤖 Prompt for AI Agents
In package.json around lines 27 to 42, add a "type": "module" top-level field
(near the other root-level fields) so Node/tsdown treat ESM files as .mjs by
default; this aligns produced extensions with the package "exports" entries
(ensuring ESM builds emit .mjs while CJS remain .js) and fixes mismatched output
file extensions.
Summary by CodeRabbit
rel: relative-ci/roadmap#70