migrate to tsdown - #517
Conversation
|
Warning Review limit reached
Next review available in: 44 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
WalkthroughThe package now uses ES module mode and migrates its build script, development dependency, and configuration provider from ChangesBuild Tool Migration
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Line 59: Align the build workflow with the Node.js requirements of the tsdown
dependency declared in package.json. Keep Node.js 20 in the overall test matrix,
but skip npm run build for that runtime, or pin tsdown to a version supporting
Node.js 20; preserve builds for supported Node.js versions.
- Line 5: Complete the ESM migration before retaining "type": "module": rename
babel.config.js to babel.config.cjs or convert it to an ESM default export so
Jest can load it, then update package entrypoints to the tsdown-generated CJS
and ESM filenames instead of .mjs and define matching import/require conditional
exports.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: f5f46fd8-be64-434c-ae68-db776764d810
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (2)
package.jsontsdown.config.ts
| "name": "@airframes/acars-decoder", | ||
| "version": "1.9.1", | ||
| "description": "ACARS Message Decoder for TypeScript/JavaScript", | ||
| "type": "module", |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== package.json excerpt =="
if [ -f package.json ]; then
cat -n package.json | sed -n '1,120p'
else
echo "package.json not found"
fi
echo
echo "== babel config files =="
fd -a 'babel\.config\.(js|mjs|cjs)$' . || true
echo
echo "== package metadata type/main/module/exports/tests/scripts =="
python3 - <<'PY'
import json, pathlib
p = pathlib.Path("package.json")
if p.exists():
data = json.loads(p.read_text())
for key in ["type","main","module","exports","scripts","devDependencies"]:
print(f"{key}: {data.get(key)!r}")
PY
echo
echo "== tsdown config files =="
fd -a 'tsdown\.config\.(js|mjs|ts|cjs)$' . || trueRepository: airframesio/acars-decoder-typescript
Length of output: 3525
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== babel.config.js =="
sed -n '1,220p' babel.config.js | cat -n
echo
echo "== tsdown.config.ts =="
sed -n '1,180p' tsdown.config.ts | cat -n
echo
echo "== lockfile tsdown/@babel/core versions if present =="
if [ -f package-lock.json ]; then
python3 - <<'PY'
import json
from pathlib import Path
d=json.loads(Path("package-lock.json").read_text())
def print_pkg(name):
root=d.get("packages",{}).get("",{}).get("dependencies",{}).get(name)
deps=d.get("packages",{}).get(name)
print(name, "root_version=", root.get("version"), "lock_version=", deps.get("version") if deps else None)
for name in ["tsdown","`@babel/core`","babel-jest","`@types/jest`","jest"]:
print_pkg(name)
PY
fi
if [ -f package-lock.json ]; then
rg -n '"tsdown"|\\n|"`@babel/core`"|\"babel-jest"|\"jest\"' package-lock.json | head -40
fiRepository: airframesio/acars-decoder-typescript
Length of output: 879
🌐 Web query:
Babel config files babel.config.js Node ESM package.json type module module.exports
💡 Result:
When your package.json contains "type": "module", Node.js treats all.js files in that directory as ECMAScript Modules (ESM) [1][2]. Consequently, if you have a babel.config.js file in this environment, it must follow ESM syntax (using export default) rather than CommonJS syntax (using module.exports) [3]. If you attempt to use module.exports inside a babel.config.js file within an ESM package, you will likely encounter an error such as "ES Modules may not assign module.exports" [4]. To resolve or manage this configuration, you have several options: 1. Use ESM Syntax: Change your babel.config.js to use export default: export default { presets: [...], plugins: [...] }; Note that Babel config files are generally required to be synchronous [5]. If your configuration logic requires asynchronous operations, be aware that native ESM config files (.mjs or.js in an ESM package) may throw errors if Babel is called synchronously [5][6]. 2. Use.cjs Extension: Rename your file to babel.config.cjs. Files with the.cjs extension are always treated as CommonJS by Node.js, regardless of the "type": "module" setting in your package.json [1][2][5]. This allows you to safely continue using module.exports [5]. 3. Use.json Extension: If your configuration is static and does not require dynamic JavaScript logic, you can use babel.config.json [7][5]. This avoids the module format issue entirely [3]. In summary, Babel dynamically interprets the format of.js config files based on the nearest package.json "type" field [1][5]. For ESM projects, either use ESM syntax in your.js file or explicitly use the.cjs extension for CommonJS compatibility [1][5].
Citations:
- 1: https://github.com/babel/website/blob/master/docs/config-files.md
- 2: Loading .cjs config files on Node 13 babel/babel#10595
- 3: Babel-node not working with "type": "module" in package.json babel/babel#11108
- 4: Error: ES Modules may not assign module.exports or exports.*, Use ESM export syntax, babel/babel#12709
- 5: https://babeljs.io/docs/config-files
- 6: Support for ESM style Babel config files, calling Babel in async fixed? babel/babel-loader#894
- 7: https://babeljs.io/docs/configuration
🌐 Web query:
tsdown output format cjs esm file extension index.cjs index.js package.json module file
💡 Result:
In tsdown, output formats and file extensions are configurable to support modern (ESM) and legacy (CommonJS) environments [1][2]. Output Formats You can specify the output format using the format option in your configuration file or CLI [1][3]. For dual-format builds, pass an array: format: ['esm', 'cjs'] [2][4]. File Extensions and Defaults By default, tsdown uses the following extensions [5][6]: - ESM:.mjs - CJS:.cjs If "type": "module" is present in your package.json, tsdown defaults to.js for ESM output [5][4]. You can customize extensions using the outExtensions option [2][5]: outExtensions({ format }) { return { js: format === 'esm'? '.js': '.cjs', } } Package.json Exports tsdown can automatically generate the exports field in your package.json, which is recommended for modern projects to ensure proper module resolution [7][4]. You can enable this by setting exports: true in your configuration [7]. Example Configuration // tsdown.config.ts import { defineConfig } from 'tsdown'; export default defineConfig({ entry: ['src/index.ts'], format: ['esm', 'cjs'], dts: true, exports: true, // Automatically generates package.json exports outExtensions({ format }) { return { js: format === 'esm'? '.js': '.cjs', }; }, }); This configuration will produce outputs such as index.js (ESM) and index.cjs (CJS), and automatically map them in your package.json under the exports field [7][4]. For legacy support, you can enable exports.legacy to generate the main, module, and types fields [7][4].
Citations:
- 1: https://tsdown.dev/options/output-format
- 2: https://github.com/antfu/skills/blob/HEAD/skills/tsdown/references/option-output-format.md
- 3: https://github.com/rolldown/tsdown/blob/84b7c34e/docs/options/output-format.md
- 4: https://tsdown.dev/guide/how-it-works
- 5: https://github.com/JetBrains/skills/blob/e0f258b5cfed145015cb3e48da9a97947f7c4ed7/tsdown/references/option-output-directory.md
- 6: https://github.com/antfu/skills/blob/50deaeb269d80d92db7a2c5a677290309ae307fc/skills/tsdown/references/option-output-directory.md
- 7: https://github.com/rolldown/tsdown/blob/84b7c34e/skills/tsdown/references/option-package-exports.md
🌐 Web query:
tsdown exports outExtensions babel.config.js package.json type module
💡 Result:
In tsdown, the configurations related to your query function as follows: Exports and Extensions The exports field in package.json can be automatically generated by setting exports: true in your tsdown.config.ts [1][2]. When enabled, tsdown infers your exports based on your build outputs [1][3]. For subpath exports, you can use the extensions option within the exports configuration to append a.js extension to keys (e.g., "./utils.js" instead of "./utils"), which follows Node.js recommendations [4][5][6]. Output Extensions To control output file naming, you can use the outExtensions option in your configuration [7]. This allows for custom extensions and overrides the default fixedExtension behavior, which typically defaults to.mjs or.cjs when the platform is set to node [7][2]. Package Type If your package.json specifies "type": "module", tsdown automatically detects this and will use the.js extension for ESM output instead of.mjs [2][8]. Babel Configuration tsdown does not use babel.config.js by default, but you can integrate Babel via plugins [9]. To use Babel, you can install @rolldown/plugin-babel and add it to the plugins array in your tsdown.config.ts [9][10]. This allows you to apply Babel transformations—such as the React Compiler—during the bundling process [9].
Citations:
- 1: https://tsdown.dev/options/package-exports
- 2: https://tsdown.dev/guide/how-it-works
- 3: https://tsdown.dev/llms-full.txt
- 4: https://github.com/rolldown/tsdown/blob/d424e089/src/features/pkg/exports.ts
- 5: https://github.com/rolldown/tsdown/blob/5de04adf/src/features/pkg/exports.ts
- 6: feat(exports): add
extensionsoption for subpath export keys rolldown/tsdown#899 - 7: https://github.com/rolldown/tsdown/blob/daed0cd008fdc0c821d229bffbcc8e451209e4ad/src/config/types.ts
- 8: https://github.com/rolldown/tsdown/blob/84b7c34e/docs/guide/how-it-works.md
- 9: https://github.com/rolldown/tsdown/blob/84b7c34e/docs/recipes/react-support.md
- 10: https://www.jsdelivr.com/package/npm/@rolldown/plugin-babel
Complete the ESM migration before enabling `"type": "module"$.
s scripts, jest also reads babel.config.js. With "type": "module", that file is parsed as ESM, but it still uses CommonJS module.exports, so npm test cannot load the Babel config. Rename it to babel.config.cjs or convert it to export default.
The tsdown config already has format: ['cjs', 'esm'], so package.json entrypoints should not use .mjs. Update main/module to the generated ESM/CJS files produced with "type": "module" and add conditional exports for import and require, or let tsdown generate them.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 5, Complete the ESM migration before retaining "type":
"module": rename babel.config.js to babel.config.cjs or convert it to an ESM
default export so Jest can load it, then update package entrypoints to the
tsdown-generated CJS and ESM filenames instead of .mjs and define matching
import/require conditional exports.
| "ts-jest": "^29.2.6", | ||
| "ts-node": "^10.9.2", | ||
| "tsup": "^8.4.0", | ||
| "tsdown": "^0.22.14", |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
npm view tsdown@0.22.14 engines --json
rg -n 'node-version:|npm run build' .github/workflowsRepository: airframesio/acars-decoder-typescript
Length of output: 880
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "package.json:"
cat -n package.json | sed -n '1,90p'
echo
echo "workflow files:"
fd -a '.*\.ya?ml$' .github/workflows -x sh -c 'echo "--- $1"; cat -n "$1"' sh {}Repository: airframesio/acars-decoder-typescript
Length of output: 5244
Align the build job with tsdown 0.22.14.
tsdown@0.22.14 requires Node.js ^22.18.0 || >=24.11.0, but the test workflow runs npm run build on Node.js 20.x too. Keep the supported runtime matrix, but exclude Node.js 20 from the tsdown build step, or use a tsdown version compatible with Node.js 20.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@package.json` at line 59, Align the build workflow with the Node.js
requirements of the tsdown dependency declared in package.json. Keep Node.js 20
in the overall test matrix, but skip npm run build for that runtime, or pin
tsdown to a version supporting Node.js 20; preserve builds for supported Node.js
versions.
1 participant
Summary by CodeRabbit