Extension fails in an workspace with multiple tailwind configs

[filipac]

In a project I have I was wondering why it stopped working and after I debugged I discovered that there were 4 tailwind configs found and the plugin always uses the first one, but that one was not installed but belonged to an extension in OctoberCMS (not relevant, but the fact is that was found first). It failed to work cause npm install did not run in that folder. The config file I wanted was actually second in the array.

REF: #209 (comment)

I would implement this but I am not familiar with how I should run the plugin locally.

[misha]

@filipac

You can run the project locally by opening the packages/tailwindcss-intellisense directory and hitting Ctrl.F5 to launch the debugging setup.

@bradlc

I looked into adding multiple configuration support to this plugin. Basically, the language server hunts down exactly one Tailwind configuration at initialization time, making it impossible to switch without restarting the service. This needs to change.

The function getTailwindState is responsible for managing a single Tailwind configuration. What if we held an array of Tailwind configurations, one for every workspace folder, and selected which configuration to use as commands came in? The configurations would be populated at initialization time, and then re-populated whenever workspace folders change.

All of onCompletion, onHover, and onCodeAction have access to the current document via their arguments. Just before executing the command, we would update the state to whichever Tailwind configuration is running in that file's workspace.

Does that look like a sound approach?

[flolu]

We work inside a monorepo with multiple projects having a tailwind.config.js file.
Would be awesome if there was a setting to configure multiple config files.

Then we could place something like this in our repositories .vscode/setting.json:

"tailwindCSS.configFiles": [
  "project-a/tailwind.config.js",
  "project-b/tailwind.config.js"
]

[paul-vd]

I'm having the same issue inside a monorepo, currently, IntelliSense is only taking the first config file it finds in the project which is problematic.

[demeralde]

Any update on this? It's been a pain during development. The only workaround I've found is just not using workspaces, and opening each folder for my project in its own VSCode window (which is cumbersome).

[shiftgeist]

@dspacejs I currently set a symlink in the root directory to the configuration I am working on, which is not an extravagant solution.

[RXminuS]

I don't think this would need to be configured manually right @flolu ? It should just look at what file is open in VSCode and find the tailwind.config.json that is in the same subtree that matches. That way if I have one in my root that can be used (solorepo shall we call it), but if I have different projects in the same repo it will use the correct config file depending on the file that I'm trying to get information for.

Right now my workaround is to rename all config files to something not found by the plugin and then only name the one in the project I'm currently working on something that is caught. But will be using @shiftgeist's suggestion now...just meant that the plugin does actually search the whole workspace already, it's just that it stops searching the moment it found A config...regardless of wether it was relevant.

[flolu]

@RXminuS You are completely right. Preferably this change should happen automatically based on the current file.

[pixelpromis]

Are there any news here? This is a massive problem to me. As we work on a Magento 2 child theme with Tailwind we have a tailwind.config.js in the vendor folder of the tailwind base theme and one in the child theme. Of course i could delete the folders from vendor but after composer install they are back. Currently this is unusable. Still looking for a way to ignore/exclude the vendor folder but no chance.

[mreduar]

I also have the same problem. I have two configs in the same project and intellisense does not work.

[bradlc]

Hey @filipac. Re-read this issue again and I'm going to close it in favour of #348, which covers being able to configure the config path 👍