-
Notifications
You must be signed in to change notification settings - Fork 18
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
Bundle Set up #1
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor text tweaks :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TYVM for getting this going! I dropped some comments
README.md
Outdated
{# templates.base.html.twig #} | ||
|
||
{% block stylesheets %} | ||
<link rel="stylesheet" href="{{ asset('styles/app.css') }}"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a proposed change. I also wonder what @bocharsky-bw thinks about this.
Right now, the bundle works by reading assets/styles/app.scss
and outputting assets/styles/app.css
. You should then ignore this file from git. We can get fancier. Instead:
A) The user would reference the app.scss
file directly - href="{{ asset('styles/app.scss') }}"
B) Like with TailwindBundle, we would output the Sass process to an internal, temporary file - e.g. var/sass/app.built.css
C) Like with TailwindBundle, we would "swap" the contents of the styles/app.scss
file in AssetMapper for the contents of this var/sass/app.built.css
file.
The only extra step that this bundle would need that TailwindBundle did not need is:
D) "Remap" the output filename of styles/app.scss
in AssetMapper. If you do A-C, you will end up with a final file called something like public/assets/styles/app.12345abcdef.scss
- ending in .scss
, which we do not want. By decorating the core PublicAssetsPathResolverInterface, we can change the output name of this file to end in .css
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, on the one hand, linking to a CSS file is a more straightforward way... but as you said that file should be probably "gitignored", so I think it really better to link directly to the Scss file then excluding working with auto-generated file directly. And I like to make the behavior consistent with TailwindBundle 👍
Thanks for your review @weaverryan and @bocharsky-bw. I fix the syntax issues you point out, rename webmamba to symfonycasts, and now the user reference directly app.scss as in the last comment. Tell me what you thinks about all this changes! Cheers 😁🧡 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran out of time to fully review - but I have some to keep you moving! More coming hopefully tomorrow. Looking good - excited to get this done.
{ | ||
$path = $this->decorator->resolvePublicPath($logicalPath); | ||
|
||
if (str_contains($path, '.scss')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would target JUST the one .scss
file. Since we are only given the logical path here... and the root_sass
config is an absolute path, that makes it tricky.
WDYT about changing the root_sass
to be the asset mapper "logical path" instead? Then it would be easy to compare that logical path to this logical path. And, it makes sense: your "input Sass" file MUST be in an AssetMapper path for all of this to work. If we decide to make that change and it works, I'll do the same for tailwind-bundle.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum sorry I don't get what you mean here. Maybe something I miss understands with asset mapper
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments - now fully reviewed. Thanks :)
} | ||
], | ||
"require": { | ||
"php": ">=8.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
was there ultimately an extension needed for unzipping the tar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it's enable by default: https://www.php.net/manual/en/phar.installation.php
@@ -0,0 +1,3 @@ | |||
p { | |||
color: red; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this meant to be here? I'm asking because FunctionalTest
seems to create this in its setUp()
.
Also, if we set a variable then use it, the assertion in the test will be a bit more meaningful, as we'll see Sass doing its job.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this is for the SassBuilderTest
I think i have a feature request to be considered before this is merged. The request is to support compiling/watching more than one scss file. this is supported fine by the cli: this would require changing the |
That makes sense to me. I can’t immediately think why this would cause any major issues. |
@bendavies thanks for your review! I implemented the support for multiples sass files. 😁 |
src/ScssFileNameGuesser.php
Outdated
{ | ||
$fileName = basename($sassFile, '.scss'); | ||
|
||
return $outputDirectory . '/' . $fileName . '.output.css'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think this should just be $filename.css
so it aligns with the assetmapper docs nicely. also phpstorm has nice integration if the filenames match like this
great! thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some comments - but this is working really nicely now! After these comments are addressed, we should be able to merge.
Things still needed after that:
A) Adding CI
B) #2 (not a blocker for an initial release, but this would be REALLY good to have)
C) Thinking about a shared "build" bundle that Tailwind & Sass could both use - the idea being that someone could, in theory, use Tailwind AND Sass and use some central assets:build
command that would take the source contents through a small pipeline (e.g. run Sass on a file, take its output, run Tailwind on that to get the final contents).
unlink($targetPath); | ||
unlink($this->binaryDownloadDir.'/'.self::getBinaryName().'.tar'); | ||
|
||
chmod($this->binaryPath, 0777); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fails because, by default, $this->binaryPath
is null. This should actually reuse the logic from createProcess()
where it uses $this->binaryDownloadDir.'/dart-sass/sass';
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, we should move the binary into var/sass
instead of bin/...
as there is no reason for the user to wonder whether they should commit this file or not. This is how it's done in TailwindBundle - https://github.com/SymfonyCasts/tailwind-bundle/blob/main/config/services.php#L20C17-L20C22 - that's eventually passed to new TailwindBinary()
: https://github.com/SymfonyCasts/tailwind-bundle/blob/main/src/TailwindBuilder.php#L101C42-L101C56
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how I feel about that. This pretty much breaks all existing conventions of having binaries in bin
.
How about keeping in bin
and adding a recipe to add a git ignore entry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep in sync with the TailwindBundle for now. But I agree with @bendavies 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The binary is a completely hidden thing - the user would never need to run it directly (and won't commit it). My thoughts: why put it in bin/
for the user to see and worry about?
Great! Lets have a final check, all your comment should be fixed now! 😁 |
82bd41e
to
a675491
Compare
This is working fantastically! Thank you a million @WebMamba! |
No description provided.