Using c12 and adding support for /.config

[zoey-kaiser]

Is your feature request related to a problem? Please describe.

Words directly take from @pi0, as I think he states the problem perfectly:

Due to a lack of standards for where tools store their configuration, the number of top-level configuration files in projects is increasing day by day. See .config dir proposal for more context.

Describe the solution you'd like

I propose supporting .config/tailwind.config.js and .config/tailwind.js as alternative places to check and load the tailwind configuration if top-level tailwind.config.ts does not exist to unblock adopting this new convention across the ecosystem.

In Nuxt/CLI Version 3.10.1 (or more specifically c12, the config loader) this was now added. https://github.com/nuxt/cli/releases/tag/v3.10.1. You can therefore now store your nuxt.config.ts inside ./config/nuxt.config.ts.

Describe alternatives you've considered

Just the root folder.

[ineshbose]

Thanks for opening this issue - completely up to adding this!

I believe this may need the module to make use of c12 - which it doesn't yet - and I'm thinking about how this may work with configPath module option..

[pi0]

Thanks for raising issue @zoey-kaiser.

I let the implementation details to @ineshbose on how to move it forward. Both migration to c12 or using search paths to check two alternative places looks good to me 👍🏼 (c12 automatically search in [name].config.ext > .config/[name].ext > .config/[name].config.ext btw. even if name already contains .config it handles suffix-less alternatives)

AFAIK, the reason that Nuxt tailwind module supports external tailwind.config file, is IDE support for tailwind extension that picks the particular file (otherwise most of the times we prefer to use inline config inside nuxt.config/.config/nuxt.

I think it would be nice idea to have our module prepared for this change and at the same time also raise on in tailwindcss repo to ask considering it as a core feature. We might also raise another in tailwindcss-intellisense to support alternative path matching tailwind core.

[zoey-kaiser]

Amazing! Thank you to both of you! I love that this new method of handling configs is starting to be adopted in the Nuxt Ecosystem, as I feel like it is a big pain point for developers, that we kind of accepted, without every thinking of better alternatives.

If I can contribute in any way, please let me know! I would update all the sidebase modules to support this, however we do not use any kind of config files, aside from the Nuxt config!

We might also raise another in tailwindcss-intellisense to support alternative path matching tailwind core.

After looking into their code, I think it may be pretty easy to add, as they also have a CONFIG_GLOB defined to search for the config! https://github.com/tailwindlabs/tailwindcss-intellisense/blob/8d22df1b0b913c548e50a0548d807f861e9c5a2d/packages/tailwindcss-language-server/src/lib/constants.ts#L1

They also offer support to let the user define where their config is: https://github.com/tailwindlabs/tailwindcss-intellisense/tree/8d22df1b0b913c548e50a0548d807f861e9c5a2d?tab=readme-ov-file#tailwindcssexperimentalconfigfile

So, this support would already be present, we would just need to document that it needs to be done, if the tailwind config is moved1

[pi0]

Thanks for research @zoey-kaiser. Do you mind to make an issue to followup this also in tailwindcss? While they allow a custom method to define config, if we want to get rid of top level configs (for real) we need to probably extend CONFIG_GLOB and intellisense that works out of the box.

[zoey-kaiser]

Thanks for research @zoey-kaiser. Do you mind to make an issue to followup this also in tailwindcss? While they allow a custom method to define config, if we want to get rid of top level configs (for real) we need to probably extend CONFIG_GLOB and intellisense that works out of the box.

@pi0, Yes, of course! Ill link back both issues, once they are opened. Ill use your issue template for opening issues. In this regard, do we maybe want to add an issue template to https://github.com/pi0/config-dir that people can easily copy to make module authors aware of the project?

It should include:

• The problem
• The solution
• About the project (started by you etc.)
• Resources for how to integrate this?

I think this would motivate a lot more people to open issues on their favorite modules, with the only downside being that it may encourage spam, if people do not check if an issue has been opened yet.

[zoey-kaiser]

@pi0 @ineshbose I have opened a discussion on the tailwindcss repository. They only use issues for bugs which I wanted to respect.
tailwindcss/tailwindcss-intellisense also does not have its own disscussions board and redirects to the one of the main repository, where I had already opened the discussion, so I hope this one discussion can handle both projects.

tailwindlabs/tailwindcss#12958

After looking into their documentation, it seems like tailwind, does not search at a specific location for the config file, but searches the entire project for the first config it can find. Therefore no changes may be needed (aside from adjusting the module). This is the description they offer:

In order for the extension to activate you must have tailwindcss installed and a Tailwind config file named tailwind.config.{js,cjs,mjs,ts} in your workspace.

[ineshbose]

OK - I have been brainstorming on this for quite a while now. Aiming to land this in v6.13.0 where we see a little rewrite on loading config strategy (this is important as we heavily rely on tailwindcss/loadConfig, but I am looking to provide an experimental option to support Tailwind v4 in v6 of this module and that could break many things). I realise that the layer loading strategy is also quite flawed where a layer's tailwindcss options in nuxt.config aren't considered and also configPaths overrides the layer's tailwind.config.

In addition, I really want to also include #842 so that IntelliSense or any HMR can work without any extra configuration. Hopefully these will give a great base for additional features in (potentially) the final minor for v6.