How can i keep npm packages with tailwind.css working

[hellomrbigshot]

I creat a privite npm package(PackageA) with tailwind. There are some media query classes like hidden lg:flex.
Then I create another project ProjectB with tailwind, then I import PackageA in this project in main.ts.

import { createApp } from 'vue'
import App from './App.vue'
import PackageA from 'PackageA' // import component
import ''./index.css' // import tailwind.css
import 'PackageA/dist/style.css' // import PackageA css

...

createApp(App).use(PackageA).mount('#app')

I use hidden in ProjectB but no lg:flex

After I build ProjectB, I find lg:flex doesn't work. Also PackageA/dist/style.css has been bundled, but hidden in ProjectB covers hidden lg:flex
I can add 'lg:flex' in tailwind.config.js to solve this problem, but i think it's not a good solution.

purge: {
  safelist: ['lg:flex']
}

I Try to add 'PackageA/dist/style.css' in purge.content but it doesn't work.

purge: {
    content: ['./public/**/*.html', './src/**/*.{vue,js,ts,jsx,tsx}',  './node_modules/PackageA/dist/style.css']
}

Is there anyway to solve this problem.

[lmlife2016]

I have found the solution👇

#4389

my tailwind.config.js look likes below:

module.exports = {
  purge: {
    enable: process.env.NODE_ENV !== 'development',
    content: [
      './src/**/*.html',
      './src/**/*.vue',
+     './node_modules/my-component-path/**/*.{vue,js,ts,jsx,tsx}',
    ],
  },
  // ...
}

[copostic]

Shouldn't we use a method like this one ?
https://dev.to/samrobbins85/making-an-npm-package-for-a-react-component-library-with-tailwind-css-a0h

[AurelianSpodarec]

What about with TailwindCSS V4?

[hellomrbigshot]

Yeah! It works for me😄😄😄

[drusellers]

Having to map my explicit node_modules path seems a bit awkward. Is there a way to use the existing path resolution features that we use with other packages?

module.exports = {
  purge: {
    content: [
      './src/**/*.html',
      './src/**/*.vue',
      'my-component/**/*.{vue,js,ts,jsx,tsx}', // would pull in the npm package `my-component`
      '@scope/my-component/**/*.{vue,js,ts,jsx,tsx}', // would pull in the npm package `@scope/my-component`
    ],
  },
  // ...
}

[rojvv]

What about ESM?

[freshgiammi]

path.join(path.dirname(require.resolve("@acme/core")), "**/*.{mjs}") works fine for me loading modules from the output folder, but mind you I've only tested this in the monorepo I'm working on right now.

[drusellers]

That is def closer. hmm. TY

[GeorgeTaveras1231]

Just calling out that none of the approaches shared here work well with package exports or PNP.

Because require.resolve('my-package') may resolve to any arbitrary file inside the package, and the resolution will use the condition used by require (the require condition in package.json['exports']) which may not be the same condition used by a bundler (most bundlers will use the module condition before falling back to the require condition). This is a problem if a package is structured as

<root>
|_ cjs
  |_ component.cjs
|_ module
  |_ component.js // (or component.mjs)

In addition, attempting to resolve a specific folder inside a package (like require.resolve('@acme/core/src') or require.resolve('package/module') requires that the author explicitly provide this export path.

Lastly, writing ./node_modules/package/**/*.js doesn't play well with PnP which does not store modules in the node_modules folder.

Ideally, tailwind would support package resolution natively, so that it can handle resolving the files properly. And maybe even support a custom tailwind package export condition to allow package authors to explicitly list the files that can be processed by tailwind 💡

Package authors would write something like

// package.json

{
  "name": "@acme/core",
  "exports": {
    "./**/*.js": {
      "tailwind": "./path/to/my-es-component-files/**/*.js"
    }
  }
}

And consumers of the package would write

// tailwind.config.js

module.exports = {
  content: [
    "@acme/core"
  ]
}

[AurelianSpodarec]

Do you have a solution with V4?

[LouisLanganay]

It looks like the issue you're encountering is due to conflicting Tailwind CSS classes between your private npm package (PackageA) and your ProjectB setup. When importing PackageA into ProjectB, the styles from PackageA's style.css are overriding certain Tailwind CSS utilities like lg:flex, causing unexpected behavior.

Here are two possible solutions to address this problem:

Solution 1: Use Tailwind's prefix option

You can configure Tailwind CSS to prefix all classes generated by Tailwind with a specific prefix. This ensures that classes from different sources (like PackageA and ProjectB) don't conflict with each other.

1. Modify your Tailwind CSS configuration file (tailwind.config.js):

// tailwind.config.js
module.exports = {
  // other configurations
  prefix: 'tw-', // Replace 'tw-' with your desired prefix
};

With this setup, every Tailwind CSS class in your application will be prefixed with tw-, ensuring uniqueness.

Example usage:

<!-- Before -->
<div class="hidden lg:flex gap-5" />

<!-- After applying prefix -->
<div class="tw-hidden lg:flex tw-gap-5" />

Solution 2: Rename classes during PostCSS compilation

Another approach is to rename classes during the PostCSS compilation step. This can be achieved using a custom plugin in your postcss.config.js file:

1. Update your postcss.config.js to include a renaming plugin:

// postcss.config.js
module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
    function (css) {
      css.walkRules((rule) => {
        if (rule.selector.startsWith('.')) {
          rule.selector = rule.selector
            .split(' ')
            .map(selector => {
              if (selector.startsWith('.')) {
                const prefix = 'obf-'; // Replace 'obf-' with your desired prefix
                return '.' + prefix + selector.substr(1);
              }
              return selector;
            })
            .join(' ');
        }
      });
    }
  ]
};

This plugin renames all CSS classes with a specified prefix ('obf-' in this example), preventing conflicts between PackageA and ProjectB styles.

2.Utilize a function to apply this renaming to your components:

import clsx, { ClassValue } from "clsx";
import { twMerge } from "tailwind-merge";

const obfuscateClassName = (className: string, prefix: string) => `${prefix}${className}`;

export function cn(...inputs: ClassValue[]) {
  const prefix = 'obf-'; // Replace 'obf-' with your desired prefix
  const classNames = twMerge(clsx(inputs));
  return classNames.split(' ').map((className) => obfuscateClassName(className, prefix)).join(' ');
}

Exemple:

<!-- Before -->
<div class="h-5 w-5 inline-block mr-2" />

<!-- After applying prefix -->
<div class="obf-h-5 obf-w-5 obf-inline-block obf-mr-2" />

Using either of these solutions should help resolve the issue of conflicting Tailwind CSS classes between PackageA and ProjectB, ensuring that styles are applied correctly without overriding each other.

Let me know if you have any questions or need further assistance!

[craigrileyuk]

This is nothing to do with the question. Don't post Chat-GPT spam, especially when it's not remotely relevant.

[AurelianSpodarec]

Especially on GitHub, this guy trying to farm fake internet emojs lol got got a thumbs up, in reverse : d

Anyone has a solution for V4?

[nikolas-beckel]

Hey, is there a recommended way by now or do I still have to refer to my node_modules folder? Thank you.

[craigrileyuk]

Best suggestions I've seen so far involve either (1) Getting the user to wrap their entire export default {} object in a function and you modifying the config before it's passed to Tailwind, or (2) Give them a small exported function from your package that returns the necessary content string, e.g.

import { tailwindContent } from "@yourname/yourpackage";

export default {
    content: [
        "./resources/js/**/*.{js,vue}",
        tailwindContent() // will return something like "./node_modules/yourname/yourpackage/dist/**/*.{js}"
    ]
}

Personally I prefer the second approach since it doesn't mess with their existing config and you can still update the content string if you like. If you envision your project needing multiple content strings, you can always use spreading from the off:

    content: [
        ...tailwindContent()
    ]

and have your function return an array of strings.