Tailwind with monorepo & different themes

[neznayer]

Hello, I'm quite new, and I need some help.
Consider this use case: a monorepo with app-a and app-b .

• app-a has color primary: "red" in it's tailwind.config.js
• app-b has color primary: "blue" in it's tailwind.config.js
• the monorepo also has a ui package, with, say, Button.tsx component. This Button component has variant prop with "app-a" and "app-b" available values.
• This component is being imported in both app-a and app-b.
  My question is, how can this component change it's tailwind classes depending on the variant prop? Somehow I should import both tailwind configs, from app-a and app-b in the ui and select one or another, depending on the variant value.
  Any ideas?..

[ch00z00]

If you simply want to change the value of class or className with the value of variant prop, you can use clsx to implement them.
clsx is a library that allows you to change the style applied by conditional branching.

You can also use tailwind-merge to create an extensible UI component.
tailwind-merge is a library that does a nice job of className merging.

Good luck! 🍀

[neznayer]

I want to use different custom tailwind configs depending on component variant prop. So in app-a there is a bg-main color defined as say red, and in app-b the bg-main defined as say, blue.
the class names could differ for app-a and app-b.

[ch00z00]

Certainly, you can achieve this by dynamically selecting the appropriate tailwind configuration based on the variant prop value within your Button component in the UI package. Here's a general outline of how you could approach this:

1. Import Tailwind Configurations:
   In your UI package, import the tailwind configurations from both app-a and app-b.

   import tailwindConfigAppA from 'path-to-app-a/tailwind.config.js';
   import tailwindConfigAppB from 'path-to-app-b/tailwind.config.js';

2. Define a Function to Select Configuration:
   Create a function that takes the variant prop as an argument and returns the appropriate tailwind configuration.

   function getTailwindConfigForVariant(variant) {
     if (variant === 'app-a') {
       return tailwindConfigAppA;
     } else if (variant === 'app-b') {
       return tailwindConfigAppB;
     } else {
       // Return a default configuration or handle other cases
     }
   }

3. Use the Selected Configuration:
   Within your Button component, use the selected tailwind configuration to generate the appropriate classes based on the variant prop.

   import React from 'react';
   import classNames from 'classnames';
   
   function Button({ variant }) {
     const selectedConfig = getTailwindConfigForVariant(variant);
     const primaryColor = selectedConfig.theme.colors.primary;
     
     const buttonClasses = classNames(
       'rounded',
       `bg-${primaryColor}`,
       // other classes...
     );
   
     return <button className={buttonClasses}>Button Text</button>;
   }
   
   export default Button;

This approach leverages conditional imports and dynamic class generation to apply the appropriate styling based on the variant prop. Make sure to handle cases where the variant prop doesn't match 'app-a' or 'app-b' to provide fallback behavior.

Remember that dynamic imports might impact your build process, so ensure you understand how your bundler (such as Webpack) handles them and adjust your configuration if needed. Additionally, the code provided here is a simplified example, and you might need to adjust it to match your specific project structure and requirements.

[neznayer]

@ch00z00 Thank you! That looks like something that might actually work!
But there will be no intellisence, right? To get some intellisence I would have to define fixed format for all app's tailwind.config.js themes and import it as well?

[ch00z00]

You're correct that using custom class names directly might not provide the same level of intellisense and autocompletion support that you get with Tailwind CSS classes. If you want to maintain intellisense while still achieving your goal, you might need to take a slightly different approach.

Here's an alternative approach that could provide better intellisense:

1. Define Theme Variants in Tailwind Configs: In each app's tailwind.config.js, you can define custom theme variants for the main color according to the app's variant:

// In app-a's tailwind.config.js
module.exports = {
  // ...other config
  theme: {
    extend: {
      backgroundColor: {
        'main': 'red', // Define the color specific to app-a variant
      },
    },
  },
};

// In app-b's tailwind.config.js
module.exports = {
  // ...other config
  theme: {
    extend: {
      backgroundColor: {
        'main': 'blue', // Define the color specific to app-b variant
      },
    },
  },
};

2. Use Custom Class Names in Component: In your Button component, you can generate class names based on the app's theme variant:

import React from 'react';

function Button({ variant }) {
  const buttonClasses = `text-white bg-main-${variant}`;

  return <button className={buttonClasses}>Button</button>;
}

export default Button;

3. No Additional CSS: With this approach, you don't need to define extra CSS classes for each app's variant. The color values are defined in the respective Tailwind configurations.

By following this approach, you're leveraging Tailwind's theming system and keeping the customization within the app's Tailwind configuration, which provides better intellisense while still allowing dynamic customization based on the variant prop.

Note that the introduction of this approach provides better intellisense, but may introduce complexity in the handling of dynamic variant names.
It's important to carefully plan your naming conventions and how you manage the relationship between the variant prop and the theme variant name.