prep_css and prep_js are too opinionated... in my opinion 😉

[CarterQC]

TL;DR we should either remove or make prep_css and prep_js optional somehow. Also they should be documented.

I have a phoenix project setup where I need to combine a variety of css and js libraries for specific pages/uses, as well as tailwind for my general site styling. For example, using something like SurveyJS means I need to import both it's js and css. I use npm just to install and track these other js/css libraries with dependabot.

So my current setup is:

• esbuild standalone profile for importing all js in app.js
• esbuild standalone profile for importing/bundling all css in app.css except tailwind (because it can't handle the tailwind directives)
• tailwind standalone for handling tailwind in a separate tailwind.css file (just contains the tailwind directives, and any customizations to tailwind)

This works great, except that this package goes into my app.css and manually adds the tailwind directives, and also removes importing app.css from app.js (which I don't need because esbuild can just bundle app.css with separate profile, but still).

This seems heavy handed, I should be able to ultimately decide what ends up in my app.js and app.css, particularly because those get version controlled.

As far as I can see, this isn't actually documented somewhere and it only happens on install, so I was really confused why those files kept being modified when I didn't modify them. It breaks what is otherwise a really nice workflow where I combine the two standalones esbuild and tailwind (or dart_saas for that matter).

[SteffenDE]

I just came across an assets folder in my umbrella root that I did not create. Seems like the tailwind package tries to be a little bit too helpful...

[janwillemvd]

We're also happily using the esbuild setup with tailwind, but we were also confused that sometimes an app.css got generated.

[qborisb]

Yeah, perhaps automatic generation of app.css and app.js can be avoided?

[carterbryden]

Right now it's relying on app_css =~ "tailwind" (so checking if your app.css has the string tailwind anywhere in it), which id definitely brittle. It only runs on install, but in a lot of pipelines that happens repeatedly and generating code/files unexpectedly - especially during a build/CD step - can be really problematic.

Instead of:

unless app_css =~ "tailwind" do
      File.write!("assets/css/app.css", """
      @import "tailwindcss/base";
      @import "tailwindcss/components";
      @import "tailwindcss/utilities";
      #{String.replace(app_css, ~s|@import "./phoenix.css";\n|, "")}
      """)

We could simply do the opposite and warn if those don't exist.

[dvic]

I think having a warning and not generating any files is fine.

[danschultzer]

I've had the same problems with asset files being generated in an umbrella app. It's because Tailwind.install_and_run/2 will configure asset files if tailwind is not installed.

So I've opened #53 to resolve this by only configuring asset files when calling the mix tailwind.install task explicitly. This way the watcher will still install tailwind if can't be found, but it won't touch any asset files.

[josevalim]

I added --no-assets to disable the assets generation. :)