Open ponychicken opened 2 months ago
I wouldn't say that this is a bug, but it's definitely not nice behavior. The generators are meant to provide a sane default for getting started - anything relying on custom packages via node_modules is out of scope for them.
That being said, we could probably rename the app.css
file into main.css
to prevent conflicts if esbuild emits CSS as well. Then, we could add a section to the generated comment in app.js
mentioning like:
// If you have dependencies that try to import CSS, esbuild will generate a separate `app.css` file.
// To load it, simply add a second `<link>` to your `root.html.heex` file.
Wdyt?
I think that sounds like an elegant solution which doesnt require any in depth changes.
new comer here making a youtube vid about all this, spent the last hour trying to remove tailwind with no luck, why this is a default? we don't even need it with css3
There is a --no-tailwind
generator that can be used when creating the application. https://hexdocs.pm/phoenix/Mix.Tasks.Phx.New.html#module-options
oh thats good to know thx
I like the main.css route too.
I am not sure if this is a bug or needs to be documented better: In a new project, there will be tailwind, taking care of generating the
app.css
and esbuild will generate theapp.js
But if you add a new node dependency (in my case leaflet map) and its docs suggest to add some import calls to your js file in order to import necessary js and css, the setup breaks.
Once there is a call to import some css in
app.js
, esbuild will start generating anapp.css
as well. Whichapp.css
will prevail is then just a question which one of the watchers got executed last. Anyway both theapp.css
generated from esbuild and the one generated from tailwind will be non funtional. the esbuild one will lack all tailwind classes, while the tailwind one will not have the styles that your library needs.