Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config.content should be resolved relative to the config file for PostCSS dependencies #6516

Closed
mischnic opened this issue Dec 14, 2021 · 12 comments · Fixed by #9396
Closed
Assignees

Comments

@mischnic
Copy link

mischnic commented Dec 14, 2021

What version of Tailwind CSS are you using?

v3.0.2

What build tool (or framework if it abstracts the build tool) are you using?

Parcel 2 👋

What version of Node.js are you using?

16

What operating system are you using?

macOS

Describe your issue

If you have a tailwind config file like

module.exports = {
    content: ["index.html"],
    theme: {
        extend: {},
    },
    plugins: [],
}

, I think content should be relative to that config file.

However, it is resolved relative to the process's working directory.

fileOrGlob here is "index.html".

let dependency = parseDependency(fileOrGlob)

and then path.resolve(file) resolved it relative to the cwd. It should be path.resolve(path.dirname(configPath), file) instead:

message = { type: 'dir-dependency', dir: path.resolve(base), glob }
} else {
message = { type: 'dependency', file: path.resolve(normalizedFileOrGlob) }

This results in a PostCSS dependency message with a filepath of ${cwd}/index.html, regardless of where that file is actually located.

@reinink
Copy link
Member

reinink commented Dec 15, 2021

@mischnic Hey! So I think this is a totally valid idea, however this would be a breaking change, so it's not inconsequential from our perspective. It honestly might mean it has to wait until v4.0. It's too bad you didn't get this to us about a week ago — we just launched v3.0 last Thursday 😫

That said, maybe there is still something we can do to help. If you can provide more information on why this is important for Parcel (what's the primary issue you're trying to solve?), maybe there's another way to fix it. For example, maybe we can add an option in Tailwind to toggle this behavior.

Practically speaking for us, we haven't had any users over the last four years report this as an issue — at least that we can remember.

@mischnic
Copy link
Author

Here's an example of how this is broken with just PostCSS CLI and printing the messages: https://github.com/mischnic/tailwind-issue-6516

Run yarn first

Then node run.js (in the root) will behave as expected:

[
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dir-dependency',
    dir: '.../tailwind-issue-6516/src',
    glob: '**/*.html'
  },
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dependency',
    file: '.../tailwind-issue-6516/src/index.js'
  },
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dependency',
    file: '.../tailwind-issue-6516/tailwind.config.js'
  }
]

But then cd src && node ../run.js references many non-existant files (because of the src/src/ part). So watching cannot possibly work:

[
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dir-dependency',
    dir: '.../tailwind-issue-6516/src/src',
    glob: '**/*.html'
  },
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dependency',
    file: '.../tailwind-issue-6516/src/src/index.js'
  },
  {
    plugin: 'tailwindcss',
    parent: undefined,
    type: 'dependency',
    file: '.../tailwind-issue-6516/tailwind.config.js'
  }
]

And furthermore (I hadn't noticed this until now), the classes used in the code aren't actually detected in the second case. So this isn't only about the dependencies being wrong

So the fundamental question here is how you want content to work:

  • Should it be as it is now? Then having a big monorepo with many subpackage and corresponding src packages would only use the classes referenced in each subpackage (with the cwd being the subpackage)
  • Or should it actually be relative to the root. Then you'd need to copy the tailwind config file into each subproject to get the same behaviour.

@ghost
Copy link

ghost commented Jan 27, 2022

This is an issue in angular workspaces as well. Having tailwind.config.js in one of the project doesn't resolve relative paths correctly after updating to v3. One has to provide full path from the root.

config file path: projects/app/tailwind.config.js

content: [
  './projects/app/src/**/**.ts'
]

rather than

content: [
  './src/**/**.ts'
]

@Farr69

This comment was marked as spam.

@k33n8nc
Copy link

k33n8nc commented Apr 14, 2022

This is a problem for Wordpress themes also where all template files live in the root folder.

@aronggile
Copy link

aronggile commented Jul 26, 2022

Tailwind CLI user here.

This is unexpected pain point. The documentation states files referenced in the content section of tailwind.config.js should be relative to the "project root." But, that does not make sense always.

For example, I am using tailwind CLI with a build system, please.build, that copies files into an
off source temporary directory when generating build targets. Since there is no proper way to configure
the path for temporary build directory the concept of project root does not makes sense. Some sort of flag
for configuring this behavior would be nice.

@yb66
Copy link

yb66 commented Aug 23, 2022

I'm also a (new) Tailwind CLI user. Having a --config switch leads me to think that the paths are (should be) relative to the config.

I'm also using a build system that moves files to a temp dir and this makes things a little more difficult.

maybe there's another way to fix it. For example, maybe we can add an option in Tailwind to toggle this behavior.

Perhaps a boolean --paths-relative-to-config switch/option? Something like that. The default could change after a version bump and not be a problem.

Regards,
iain

@tailwindlabs tailwindlabs deleted a comment from Lee6546 Aug 27, 2022
@architchandra
Copy link

Just wasted 3 hours on this. If this can't be fixed soon, at least mention this in the documentation somewhere. Or suggest using absolute paths.

@adamwathan
Copy link
Member

Just wasted 3 hours on this. If this can't be fixed soon, at least mention this in the documentation somewhere. Or suggest using absolute paths.

Imagine how much more time you would have wasted if you had to build the entire CSS framework yourself instead of leveraging years of other peoples' work for free? Nothing is perfect, don't be a dick dude — I have absolutely zero patience for that.

@architchandra
Copy link

architchandra commented Aug 31, 2022

Hey, sorry @adamwathan.
The intent was not to be this harsh but I guess I was too sleep-deprived and frustrated to keep my emotions in check. I hugely value Tailwind and the work that you all do, so it felt quite hurtful when I saw such a strong response from you. But it was my mistake to begin with and I take responsibility for that. :)

@aronggile
Copy link

If it helps anyone, project root refers to the directory tailwind CLI is invoked from.
That is, the working directory of the CLI. Not the .git root of your project.

Maybe it was easy to miss, at least for me, but the @mischnic has stated this clearly:

I think content should be relative to that config file.
However, it is resolved relative to the process's working directory.

To make the CLI work as intended, switching to the directory containing tailwind.cofnig.js before invoking
it should do the trick.

@thecrypticace
Copy link
Contributor

thecrypticace commented Sep 23, 2022

We've prepped a feature for v3.2 (in #9396) that will allow you to do this! You can specify your content paths like so and we will look for them relative to the config file:

module.exports = {
  content: {
    relative: true,
    files: [
      "./src/pages/**/*.js",
      "./src/components/**/*.js",
    ],
  },
  // …
}

This is available in our insiders release which you can install using npm install tailwindcss@insiders

Thanks for your patience! ✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants