Please Maintain Long-Term Support for JavaScript/TypeScript Configuration in Tailwind CSS #15375

johncmunson · 2024-12-12T07:23:33Z

johncmunson
Dec 12, 2024

Description

First off, I want to thank the team for their incredible work on Tailwind CSS. It's been a game-changer for developers and has made styling in modern web development an absolute pleasure. I'm excited to see the new CSS-first configuration option in Tailwind CSS v4.0. It seems like a great addition for projects that value simplicity and minimal setup. However, I have significant concerns about the potential deprecation of JavaScript/TypeScript (JS/TS) configuration in future versions.

While I understand that JS/TS configuration will still be supported in v4.0 through the @config directive, the use of the term "legacy" in reference to JS configuration is worrisome. "Legacy" often implies that the feature is deprecated or will be phased out in the future. For many developers, JS/TS configuration is a critical and irreplaceable feature due to its flexibility, type safety, and the ability to leverage the full power of JavaScript for dynamic configuration.

Key Points

Type Safety with TypeScript: Using TypeScript for Tailwind configuration allows developers to achieve strong type safety, which significantly reduces bugs and improves developer experience. Type safety ensures that we can confidently make changes to the configuration without unintended consequences.
Dynamic and Scriptable Configurations: JavaScript's capabilities make it the ideal choice for highly dynamic or complex configurations. For example:
- Calculating values based on external data or logic.
- Generating configuration sections programmatically (e.g., creating color palettes or spacing scales).
- Using npm packages to dynamically generate sections of the config or to share and extend configuration logic across multiple projects. This powerful capability will be lost with the move to CSS-first config.
Developer Ecosystem: Many developers already have workflows and tools built around JS/TS configurations. Removing JS/TS support would force significant rewrites, impacting productivity and introducing unnecessary friction for teams that rely on this flexibility.
Complementary Nature of CSS-First Config: The introduction of CSS-first configuration is fantastic for emphasizing the CSS-first nature of this library and it eliminates the need for an extra config file, but it serves a different use case than JS/TS configurations. CSS-first config is great for quick setups and straightforward projects, while JS/TS config caters to complex, dynamic setups.

Suggestions

Reassure Developers: Please clarify that JS/TS configuration will continue to be fully supported alongside CSS-first configuration in v4.0 and beyond. Avoid terms like "legacy" that suggest future deprecation.
Document Use Cases: Provide clear documentation on when to use CSS-first configuration versus JS/TS configuration, emphasizing that JS/TS is still the preferred method for dynamic and complex setups.
Maintain Feature Parity: Ensure that both configuration methods offer comparable functionality, so developers don't feel like they have to choose between simplicity and power.

Thank you for taking the time to consider this feedback. I believe that maintaining long-term support for JS/TS configuration will ensure that Tailwind CSS continues to serve the needs of developers across the entire spectrum of project complexity.

daniel-brenot-wbd · 2025-01-08T21:17:08Z

daniel-brenot-wbd
Jan 8, 2025

I'm here to continue this discussion as I've noticed a knock on effect of this that may possibly eliminate the ability for me to use this at work.

In the previous tailwind version, I could pass the raw html into the postcss plugin like so:

   const tailwindConfig = {
        content: [ { raw: '<html><div class="tw-h-0"></div></html>', extension: 'html' },],
        prefix: 'tw-'
    };

    // Create a PostCSS processor with TailwindCSS
    const processor = postcss([
        tailwindcss(tailwindConfig)
    ]);

But now in the new version, there is no way to configure this functionality. This is a huge issue for us, and I imagine many others.

Without the js based configuration, I am unable to use the postcss plugin for this, as it has now removed the option to pass in raw html, opting only to allow you to pass in a base path. This is problematic for me, as the use case for tailwind for me was to generate classes on the fly as a part of a render pipeline.

With the new change we would need to write these files to disk, pass that file location into the postcss plugin, delete the file and then return its contents. This is far too inefficient, and possibly error prone.

I imagine other tools may also have relied on this functionality, so I worry for how this may affect them.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Please Maintain Long-Term Support for JavaScript/TypeScript Configuration in Tailwind CSS #15375

{{title}}

Replies: 1 comment

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Please Maintain Long-Term Support for JavaScript/TypeScript Configuration in Tailwind CSS #15375

johncmunson Dec 12, 2024

Description

Key Points

Suggestions

Replies: 1 comment

daniel-brenot-wbd Jan 8, 2025

johncmunson
Dec 12, 2024

daniel-brenot-wbd
Jan 8, 2025