Problem

Closes #627

When using CSS files as entries alongside JS files with the same base name (e.g., index.js and index.css), Rolldown generates an empty JS file (0 bytes) for the CSS entry, which overwrites the legitimate JS output.

Example:

// tsdown.config.ts
export default {
 entry: ['index.js', 'index.css'],
}

Before this fix:

• dist/index.js - 0 bytes (empty, generated from CSS entry)
• dist/index.css - correct CSS output
• Original index.js output was overwritten

Solution

I attempted to fix this issue by separating CSS entries from JS entries and processing them independently using LightningCSS. I'm not deeply familiar with this codebase, so please let me know if there are any issues with this approach or if there's a better way to handle this.

Key Changes

1. Separate CSS and JS entries (src/features/entry.ts)

   • Keep .css extension in entry names to avoid name conflicts
   • Add separateCssEntries() function to split entries by type

2. Direct CSS processing (src/features/css-bundle.ts)

   • New module to build CSS entries using LightningCSS transform() API
   • Preserves @import statements (not inlined)
   • Supports minify and target options

3. Watch mode support (src/index.ts)

   • Add CSS file watchers using Node.js fs.watch()
   • Debounce rebuilds (100ms) to avoid excessive builds
   • Rebuild CSS chunks on each Rolldown watch cycle to prevent them from being cleared

4. Enhanced reporting (src/features/report.ts)

   • Modified ReportPlugin to accept extra chunks (CSS chunks)
   • Unified reporting for both JS and CSS files with gzip/brotli sizes
   • Correct file counts and total sizes

Behavior Changes

After this fix:

• dist/index.js - correct JS output ✅
• dist/index.css - correct CSS output ✅
• No empty JS files generated from CSS entries ✅

Build output:

i dist/index.js 0.06 kB │ gzip: 0.08 kB
i dist/index.css 0.02 kB │ gzip: 0.04 kB
i 2 files, total: 0.08 kB
✔ Build complete in 51ms

Watch mode output:

i dist/index.js 0.06 kB │ gzip: 0.08 kB
i dist/index.css 0.02 kB │ gzip: 0.04 kB
i 2 files, total: 0.08 kB
✔ Rebuilt in 20ms.

Testing

• ✅ All 141 existing tests pass
• ✅ Updated snapshots for CSS-related tests (removed empty .mjs files)
• ✅ Manually tested with watch mode
• ✅ Lint checks pass

Implementation Details

Why use transform() instead of bundleAsync()?

I chose to use LightningCSS's transform() API instead of bundleAsync() to preserve the original behavior where each CSS file is output separately. This means:

• @import statements are preserved in the output (not inlined)
• Each CSS entry generates its own output file
• Matches the behavior of Rolldown's CSS handling for imported CSS

Watch Mode Implementation

In watch mode, there was a challenge where Rolldown's watcher would clear all chunks (including CSS chunks) on each rebuild. The solution:

1. CSS chunks are rebuilt on each Rolldown watch cycle (START event)
2. Separate file watchers monitor CSS files for changes
3. CSS file changes trigger incremental rebuilds with 100ms debouncing

Reporting Integration

The ReportPlugin was enhanced to accept a callback that provides extra chunks (CSS chunks). This allows:

• Unified reporting format for all files
• Correct total file counts and sizes
• Consistent output between normal and watch modes

Notes

• CSS @import statements are preserved in the output (not inlined)
• CSS entries require the lightningcss peer dependency
• Watch mode uses Node.js built-in fs.watch() (no additional dependencies)
• CSS chunks are re-added on each Rolldown watch cycle to prevent them from being cleared

I'm not deeply familiar with this codebase, so this is my attempt to fix the issue. Please let me know if there are any problems with this approach or if there's a better way to handle it. Thank you for reviewing! 🙏