tsdx

🐞 Bug: generates outdated and Bun-incompatible project setup Describe the Bug Running generates a project scaffold that relies on outdated and unmaintained TSDX internals. The generated includes , legacy scripts, and configurations that are not compatible with modern tooling, especially Bun. As a result, fails because Bun cannot resolve , even though the package previously existed on npm. The generated output is out of sync with current best practices and modern build tools. Steps to Reproduce 1. Run: 2. Navigate into the generated project 3. Run: 4. Observe the installation failure Expected Behavior The scaffolded project should: Use maintained, modern tooling (e.g. , , or Bun-compatible alternatives) Avoid dependencies on unpublished or archived packages Generate a that installs cleanly with modern runtimes (Node ≥20, Bun) Alternatively, should warn that: TSDX is archived / deprecated Bun is not supported Actual Behavior The generated includes: Running fails with: The generated scripts (, , etc.) are unusable in Bun and rely on deprecated tooling. Screenshots / Logs Environment Run used to collect versions: Additional Context TSDX appears to be archived / unmaintained, but still generates new projects without warning. The generated configuration does not align with: Modern ESM standards Bun’s strict dependency resolver Current React library best practices This leads to a broken first-time experience for users using Bun or modern Node tooling. Suggestion:** Deprecate , or Explicitly document that Bun is unsupported and the tool is legacy.

Problem fails during with: Both template files referenced , but the package is at . Fix Updated both template files to use Added dynamic version injection in the command to set the tsdx devDependency based on the CLI's current major version, preventing future version mismatches Closes #1206

Problem Statement When building a library with tsdx v2, component-level CSS files (those imported directly in files like ) are processed by bunchee's rollup plugin, which runs v5.3.3 with default options (). clean-css v5.x has no support for native CSS nesting. Its tokenizer only handles at for CSS custom property values and margin boxes — there is no handler for the native nesting case (e.g. ). When it encounters nested in a rule context, it falls through to a generic buffer push, corrupting the token stream and silently mangling or dropping the nested styles in the output. This means any component-level CSS file that uses native CSS nesting syntax will produce broken output after the tsdx build, with no error or warning. ### Proposed Solution Replace clean-css with a CSS minifier that supports native CSS nesting, such as Lightning CSS or cssnano (via PostCSS). Alternatively, make the CSS minifier configurable so consumers can provide their own. In bunchee's , the relevant code is: This could be swapped to Lightning CSS: Lightning CSS has full support for native CSS nesting and is significantly faster than clean-css. ### Alternatives Considered Pre-flattening nesting with PostCSS/Tailwind before the build: This works for styles that go through a dedicated CSS compilation step (e.g. Tailwind's --minify flattens nesting), but doesn't help component-level CSS files that are imported directly in components and processed by bunchee's inlineCss plugin. Disabling CSS minification entirely in bunchee: Avoids the corruption but sacrifices minification for all CSS. Avoiding native CSS nesting in component CSS files: A workaround, but native CSS nesting is a stable browser feature (supported in all major browsers since Dec 2023) and developers should be able to use it. Who Benefits? Any library author using tsdx/bunchee who wants to use native CSS nesting in component-level CSS files. As CSS nesting adoption grows (it's now baseline across all major browsers), this will affect an increasing number of users. Additional Context clean-css v5.x is effectively in maintenance mode and has no plans to add nesting support — the tokenizer's Level system would require a significant architectural rewrite. bunchee v6.9.4 pins clean-css: ^5.3.3 as a direct runtime dependency. tsdx v2.0.0 delegates entirely to bunchee via execa("bunchee"). The issue is silent — clean-css produces corrupted output without any errors or warnings, making it difficult to diagnose.