How to use with webpack?

[spingary]

Hi there!

I can't seem to find a way around the ES Modules issue when using webpack. (Actually, I am using Laravel Mix which uses webpack.)

"import" statements cannot be used in webpack configuration files. Any hint as to how I can set this up is most appreciated.

Thank you!

[KevinAst]

I'm afraid I am not at all proficient in webpack. I would be relegated to using google search, which I'm sure you have already done.

To get you going (as a temporary work-around), you could manually extract the results of TwThemes.colorConfig() (through a temporary snippet of your app's run-time), and inject this into your tailwind.config.js (hard coded). This is NOT ideal, because it is NOT dynamic ... so any change to your schema would require another manual regeneration. With that said, your schema is typically fairly static, so it would rarely change.

I would encourage you to continue to search for a permanent solution. Please reply to this issue with your findings, so others may benefit. In addition, I can update the docs with your findings.

Sorry I couldn't be of more assistance.

[violacase]

Any more knowledge on this now for I can't get it done in Vite (with Vue3)? If so it would be nice if you could make a GitHub demo setup branche for Vite and/or Webpack. It's unfortunate the module and setup process as you describe only works for Svelte with Rollup. I am really in love with your project but am stuck! Please...

[KevinAst]

Hello @violacase,

As I mentioned previously, I'm a bit of a novice on bundler options and configurations.

As you know, this issue is related to the build process (i.e. tailwind configuration), and not the TwThemes run-time itself. Because we are attempting to invoke, what is in essence some app-level code in the configuration of tailwind, we are experiencing issues related to ES Modules (i.e. import/export) in the build process.

I did a quick google search on "tailwindcss configuration with ES Modules", and while I found a couple of issues, they do not appear to be very active.

• TailwindCSS fails in an esm project #2284
• Esmodule breaks, cljs config extension is recommended but not found #7153

With that said, I'm thinking about documenting an alternate approach to the tailwind configuration setup that will work in all environments. You can actually use this approach now, so please don't let this issue be a sticking point that prevents you from using tw-themes :-)

My thought is to promote an alternative configuration process that bypasses the direct invocation of TwThemes.colorConfig() in tailwind.config.js.

If you think about it, the color theme structure in your project very rarely changes. You can simply extract the content result of TwThemes.colorConfig(), and inject it manually ... either directly in the tailwind.config.js file, or an intermediate json file that is in turn included in your tailwind.config.js. In this setup, you would only need to re-extract this content anytime the structure of your context-colors changes (i.e. context color names changes).

This could even be semi-automated through a unit test, that performed the extraction (invoking TwThemes.colorConfig()), and comparing it's content to the last-known content. This way, you would systematically know when it was necessary to change the content of the color configuration resource (which again, would be very rarely).

This in essence is a modified rendition of the "temporary work-around" that I mentioned above (on 11/12/2021).

I am currently a bit over-taxed, but I would encourage you to give this a try. It should be extremely simple to accomplish. Report back to me, and I will consider updating the formal documentation with this alternate approach.

</Kevin>

[violacase]

Hi Kevin,
Many thanks for your fast and interesting reply!
I'm also an old school dev (67 years old)
I understand your points and suggestions. This bundler stuff for me is far too difficult. I'm using Vue for developing my simple personal web sites.
If you could create something like this https://codesandbox.io/s/immutable-monad-cotsz?file=/src/App.vue with your new approach you'd make me a happy guy!
(By creating a codesandbox demo all pieces come together. Easy to adept. )

NB: I noticed one hour ago that codesandbox itself has problems with Vite and ALSO with Tailwind environment. Gr.....
(building error on tailwind.config.js : 'module' is not defined)

If you'll find the time to solve all this issues I'm extra happy. If not let it be. Than I rest also happy. Thanks again.

[KevinAst]

The dirt simplest thing you can do is to merely inject some temporary code that emits the configuration to your console log, and then copy/paste that configuration into your tailwind.config.js.

In the Getting Started section of the docs:

• Step 3 Inject the following code at the end of Step 3:

  // right after this (from the docs) ...
  const TwThemes = initTwThemes(schema, themes);
  export default TwThemes;
  
  // do this ...
  // temporary code to emit our tailwind color configuration
  console.log('Place this config in your tailwind.config.js\n' + 
              JSON.stringify(TwThemes.colorConfig(), null, 2));

  This will emit something like the following in your console log (I'm showing my colors, your structure will vary, depending on your schema):

  Place this config in your tailwind.config.js
  {
    "primaryLight":   "var(--twt-primaryLight)",
    "primary":        "var(--twt-primary)",
    "primaryDark":    "var(--twt-primaryDark)",
    "secondaryLight": "var(--twt-secondaryLight)",
    "secondary":      "var(--twt-secondary)",
    "secondaryDark":  "var(--twt-secondaryDark)",
    "onLight":        "var(--twt-onLight)",
    "onDark":         "var(--twt-onDark)",
    "accentBorder":   "var(--twt-accentBorder)",
    "backdrop":       "var(--twt-backdrop)"
  }
  

• Step 4 Simply copy/paste your logging probe content directly into your tailwind.config.js ... in place of the TwThemes.colorConfig() invocation:

  module.exports = {
    ... snip snip
    theme: {
      extend: {
        colors:  { // replacing TwThemes.colorConfig() with output of our logging probe
          "primaryLight":   "var(--twt-primaryLight)",
          "primary":        "var(--twt-primary)",
          "primaryDark":    "var(--twt-primaryDark)",
          "secondaryLight": "var(--twt-secondaryLight)",
          "secondary":      "var(--twt-secondary)",
          "secondaryDark":  "var(--twt-secondaryDark)",
          "onLight":        "var(--twt-onLight)",
          "onDark":         "var(--twt-onDark)",
          "accentBorder":   "var(--twt-accentBorder)",
          "backdrop":       "var(--twt-backdrop)"
        }
      }
    },
    ... snip snip
  }

This simple solution does not include the "extra credit" exercise of semi-automating the process through a unit test, but it will get you going. You will need to re-execute this procedure anytime your context color names change (i.e. that is the only thing that will change the output of TwThemes.colorConfig()).

Hope this helps.

</Kevin>

[violacase]

My tailwind.config.js looks like this: `
module.exports = {
content: [
"./index.html",
"./src/**/*.{vue,js,ts,jsx,tsx}",

],

corePlugins: {
preflight: true,
},

plugins: [

],
darkMode: "class",
}
`
Importing in this config.js is not possible for as far I can see.

[KevinAst]

Sorry, I was mixing in the ES Module syntax, which is no longer applicable with this new approach.

I have edited my previous reply appropriately (see Step 4). The theme structure is a new section you need to add in your existing configuration (represented by the ... snip snip).

[violacase]

Another problem: import initTwThemes from "tw-themes" in main.js gives the the following error: Could not find a declaration file for module 'tw-themes'.
It's looking at: ...path.../node_modules/tw-themes/lib/index"

I DO find it physically in the node tree however.

[KevinAst]

This is a named import, so you need squiggles around the name:

import {initTwThemes} from 'tw-themes';

[violacase]

Same issue... I'm sure it's not the project's set up for all other imports work.
Looking at that index.js it reports: File is a CommonJS module; it may be converted to an ES module

[KevinAst]

hmmm ... My library bundling process is using a pure babel solution (see the "lib:build" npm script in package.json).

In looking at the bundles index.js it is in fact a CommonJS module.

The odd thing is I do not have an issue importing it in my Svelte project, and I have not had any complaints from other users.

Is this error occurring at runtime of of your Vue app or in the build process of Vite?

I'm really unsure how to proceed on this. I'm wondering if there is some Vite configuration that may solve the problem?

[violacase]

No, not in run time. The built in checker of vscode editor reports this. I think you have to refactor your files thus they become pure ES modules.