¿Un mundo sin sistemas de construcción?

Hey Marius,

Thanks for this tip! Please, correct me if I'm wrong, but I don't see we use Symfony secrets in this course. Is it something that you use internally for your project?

Cheers!

Hey Victor,

It's not being used in the course, but the downloadable code contains a secret called GITHUB_TOKEN (with the value "CHANGEME" in dev). I guess it's the one from chapter 21 in the "Symfony 6 Fundamentals: Services, Config & Environments" course.

Not a big deal, especially if you go through the courses in order. I just happened to do the courses on different computers and this one didn't have sodium installed yet.

Yea... this is a good tip - for some reason, some PHP installs still don't have Sodium. And, as you said, it's not actually needed. I think we can comment-out its usage to avoid the error entirely.

OR create a .env.local file with this env var if you wont install sodium ;)

Thanks @Jared and I also agree this is way better than Webpack

Cheers!

Since this course is all about not needing a build system, I think you should check in the app.tailwind.css file, so that the 'finish' file works.

Otherwise, you have to build the css file, but then there should be installation instructions in the README. The tailwind bundle downloads the executable, but there appears to be no way to run the bin/console command and get the output file in the right directory. Downloading the tailwind binary works better (since the tutorial has instructions on how to run it).

So after way some playing around, I was able to build the finished project. But please, either add the tailwind css file or the build instructions to the readme of the 'final' folder.

I LOVE AssetMapper. I can't wait to understand it enough to drop the build system.

Hey Tac!

I think you should check in the app.tailwind.css file, so that the 'finish' file works.

Ah, good idea actually :). Btw, now that https://github.com/symfonycasts/tailwind-bundle exists, adding Tailwind is even easier, and you don't need to think about this app.tailwind.css file anymore.

I LOVE AssetMapper. I can't wait to understand it enough to drop the build system.

It's going to get even better in 6.4! We just merged CSS support, smarter preloading & it looks like downloading vendor files locally (vs using the CDN) will be a first-class citizen. Good stuff coming!

Cheers!

Yes, the tailwind bundle is better.

But there appears to be no '-o' option to write the file:

bin/console tailwind:build -vvv

! [NOTE] Executing Tailwind (pass -v to see more details).

Command:

'/home/tac/g/tacman/asset-mapper/var/tailwind/tailwindcss-linux-x64' '-i' '/home/tac/g/tacman/asset-mapper/assets/styles/app.css' '-o' '/home/tac/g/tacman/asset-mapper/var/tailwind/tailwind.built.css'

So how to do you use the tailwind bundle CLI to run this command?

./bin/tailwindcss -i assets/styles/app.css -o assets/styles/app.tailwind.css

Hey Tac!

No -o option is needed :). With the tailwind bundle, you run:

bin/console tailwind:build

... and that's it :). Internally, this outputs the built file into the var/tailwind/ directory, but you don't care about this. Further explanation! Assume your source Tailwind file is assets/styles/app.css:

A) In base.html.twig, you create a link tag directly to THIS file: {{ asset('styles/app.css') }}
B) At this point, if TailwindBundle wasn't here to rescue us, then our user would be served the source, uncompiled Tailwind app.css file, which is not what we want!
C) But, behind the scenes, when AssetMapper fetches assets/styles/app.css to return to the user, TailwindBundle intercepts that process, grabs the built contents (from the var/tailwind/ directory) and tells AssetMapper to use THOSE.

The end result is that: (1) you create a link tag directly at the source app.css file (2) but the user is served the built file and (3) you don't care at all where the actual built file lives - that's handled internally.

Does that make sense? You have to untrain your mind after watching this tutorial - because that bundle makes it so much easier.

Cheers!

I see my problem -- with the bundle, the css file is app.css. In the tutorial, it uses a specific tailwind.css file.

Hey @Nayte91!

I think this is a VERY legitimate question :). Somehow, though it feels totally normal to have 15 import statements for CSS files, it feels weird to have 15 link tags for those same 15 CSS files :). But I think we should not feel weird about this: we need to list all 15 CSS files somewhere, there's not really any difference between doing it as import statements of link tags :).

However, I think you might be referring more to the possible issue that 15 link tags means 15 requests for those CSS files, vs the 1 that this would compile to in Webpack. With HTTP/2, this is largely not a concern. However, there is certainly SOME upper limit where it is a problem (e.g. imagine you have 1000 CSS files), but I'm not sure where that is. My advice is to put those as 15 links tags and run Lighthouse on it to be sure it's not a problem. You could even - as we do in the last chapter - send a preload header to hint even EARLIER that these file are needed - https://symfonycasts.com/screencast/asset-mapper/preloading#preloading-via-a-header

My guess is that putting 15 link tags is a non-issue, but I get that it feels weird :). Time will tell whether this is something that we al "get used to" or if, perhaps, so many people find it weird for some reason that we add a layer to combine the files. But I'm hoping it doesn't come to that: that's the point of HTTP/2, it removes that need for combining files (so I hope we won't need to re-add it for some reason).

Cheers!

yep it is SO, when you are using modern browser, honestly pretty unbelievable, I remember the times of IE6 and now you can just write modern JS and it will work.... awesome thing!

Cheers!