Tailwindcss-module: Slow nuxt build! what should I do?

Created on 23 Oct 2020 · 5Comments · Source: nuxt-community/tailwindcss-module

Without Tailwindcss

✔ Client
  Compiled successfully in 2.12m

✔ Server
  Compiled successfully in 1.72m


Hash: 36fc5cf6354758073391
Version: webpack 4.44.1
Time: 127192ms

With Tailwindcss

✔ Client
  Compiled successfully in 26.23s

✔ Server
  Compiled successfully in 7.20s


Hash: 2a16c82743dd11e56513
Version: webpack 4.44.1
Time: 26232ms

tailwindcss css

@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';

tailwindcss config js

const extend = {
  spacing: [-10, 200],
  inset: [0, 100],
  colors: {
    red: {
      default: '#FF3C3C',
      FFEEEE: '#FFEEEE',
    },
    blue: {
      default: '#5572FD',
      E8ECFF: '#E8ECFF',
    },
    green: '#50B349',
    yellow: {
      default: '#FF9807',
      FDC31F: '#FDC31F',
      FEF3E5: '#FEF3E5',
      FFE9D6: '#FFE9D6',
      FFEACC: '#FFEACC',
    },
    gray: {
      default: '#989898',
      656565: '#656565',
      F2F2F2: '#F2F2F2',
      E5E5E5: '#E5E5E5',
    },
  },
}

function expandThemeByPx (array) {
  const expand = {}
  const [start, end] = array
  let current = start
  while (current <= end) {
    expand[current] = `${current}px`
    current++
  }
  return expand
}

module.exports = {
  // important: true,
  future: {
    removeDeprecatedGapUtilities: true,
    purgeLayersByDefault: true,
    defaultLineHeights: true,
    standardFontWeights: true,
  },
  theme: {
    extend: {
      spacing: expandThemeByPx(extend.spacing),
      inset: expandThemeByPx(extend.inset),
      colors: extend.colors,
    },
    fill: extend.colors,
  },
  variants: {},
  plugins: [],
  purge: {
    // Learn more on https://tailwindcss.com/docs/controlling-file-size/#removing-unused-css
    enabled: process.env.NODE_ENV === 'production',
    content: [
      'src/components/**/*.vue',
      'src/layouts/**/*.vue',
      'src/pages/**/*.vue',
      'src/utils/common.js',
    ]
  }
}

nuxt config js

{
tailwindcss: {
    configPath: '~~/tailwind.config.js',
  },
}

HELP HELP

pending

Source

Yee1014

👍3

Most helpful comment

I also found some performance problems migrating from tailwind 1.x to 2.x In my case, it was related to using @apply inside components.

I created this issue on the tailwind repo https://github.com/tailwindlabs/tailwindcss/issues/3717 and the following PR https://github.com/tailwindlabs/tailwindcss/pull/3718 . I am waiting for the tailwind team feedback

axelhzf on 9 Mar 2021

👍2

All 5 comments

I have the same problem.

There will be a white screen when scrolling the webpage in safari.

package.json

"dependencies": {
  "nuxt": "^2.14.5",
},
"devDependencies": {
  "@nuxtjs/tailwindcss": "^3.0.2",
}

nuxt.config.js

buildModules  buildModules: [
    '@nuxtjs/tailwindcss',
  ],

tailwind.config.js

module.exports = {
  future: {
    removeDeprecatedGapUtilities: true,
    purgeLayersByDefault: true,
  },
  purge: {
    // Learn more on https://tailwindcss.com/docs/controlling-file-size/#removing-unused-css
    enabled: process.env.NODE_ENV === 'production',
    content: [
      'components/**/*.vue',
      'layouts/**/*.vue',
      'pages/**/*.vue',
      'plugins/**/*.js',
      'nuxt.config.js',
    ],
  },
  theme: {
    maxHeight: {
      16: '4rem',
    },
    borderWidth: {
      default: '1px',
      0: '0',
      2: '2px',
      3: '3px',
      4: '4px',
      6: '6px',
      8: '8px',
    },
    extend: {
      colors: {
        primary: {
          light: '#ffd943',
          default: '#ffb01c',
        },
        secondary: {
          light: '#ffe3d7',
          default: '#ff6d2d',
          dark: '#99411b',
        },
        customGray: {
          100: '#faf9f5',
          200: '#f0f0f0',
          300: '#ebebeb',
          400: '#dcdcdc',
          500: '#b4b4b4',
          600: '#969696',
          700: '#615a50',
        },
        customBlue: {
          dark: '#36568d',
          light: '#798fa7',
        },
        customPink: {
          default: '#eaac9d',
        },
        customBlack: {
          default: '#1e1e1e',
        },
        customYellow: {
          light: '#fdf6e9',
          default: '#b49d73',
        },
      },
      height: {
        90: '90px',
        100: '100px',
        110: '110px',
        150: '150px',
      },
      inset: {
        '-2': '-0.5rem',
        25: '25%',
        50: '50%',
        75: '75%',
        100: '100%',
        '-50': '-50%',
        '-100': '-100%',
      },
      zIndex: {
        '-10': '-10',
        100: '100',
      },
      boxShadow: {
        10: '0 0 10px rgba(0, 0, 0, 0.05)',
      },
    },
  },
  variants: {},
  plugins: [],
}

Can be solved with this method
But it doesn't seem to be the best solution.

one-liang on 26 Oct 2020

👎1

We aware of this issue and actually this is directly related to TailwindCSS: https://github.com/tailwindlabs/tailwindcss/issues/2544

We are actually thinking of a way to accelerate the development build and hot module replacement, the idea would be to generate the CSS manually with the Tailwind config and PostCSS when loading the module, then inject the CSS once to we bypass the PostCSS plugin for Tailwind, but may have side effects.

Atinux on 2 Nov 2020

Just to chime in - isn't it also a case where separating tailwindcss imports from tailwind.css file would help? According to https://nystudio107.com/blog/speeding-up-tailwind-css-builds (mentioned in the issue you linked before) would suggest that splitting imports into separate entry points would speed up recompilation on change. I don't know how it works underneath, but I can image that cssPath would act as an array for tailwindcss/base tailwindcss/utils etc and a separate entry for tailwind.css which wouldn't import them. Then each change to custom classes would only trigger recompilation of custom classes and not the whole tailwindcss. Is this possible?

janslu on 19 Dec 2020

After getting to Memory usage: 1.59 GB (RSS: 1.83 GB) for a very basic site that took about 30s on every @apply directive for components I wondered what was up. Same happening here, pushing about 60MB of CSS and Sourcemaps through the HMR.

So my workaround was to never do purge: { enabled: process.env.NODE_ENV === 'production' } and just force it to enabled: true.

Not sure where I got that line from. If you purge, you want to purge in production and development. If a CSS class is missing because of the purge, you want it to happen in both environments and the correct purge settings should work on development as well.

At least my four-pager became usable again after HMR pushes and the initial CSS is only about 2MB with sourcemaps. The initial build still takes forever and memory usage is still of the charts though.