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

Central AssetMapper "build" bundle? #4

Open
weaverryan opened this issue Aug 18, 2023 · 8 comments
Open

Central AssetMapper "build" bundle? #4

weaverryan opened this issue Aug 18, 2023 · 8 comments

Comments

@weaverryan
Copy link
Contributor

It should be possible (even if it's not a super normal thing to do) to combine this bundle and https://github.com/SymfonyCasts/tailwind-bundle.

To do that, there could be a central asset-mapper-build-bundle which defines a command like assets:build. Then, this bundle and TailwindBundle could hook into that. This would allow to:

A) Compile the SASS from an app.scss file to pure CSS.
B) Then process that pure CSS through Tailwind.

Additionally, it would be GREAT if the new bundle could hook into the asset-map:compile command so that, before the files are actually compiled, the "build" pipeline were called. So, instead of needing to run assets:build and then asset-map:compile during deploy, you could just run asset-map:compile and it would trigger the assets:build system. This would likely require a new event in the core AssetMapper asset-map:compile command.

@squrious
Copy link
Contributor

Hello! I took a look on this. Here are some thoughts:

I think a good approach could be to have an event-based pipeline system. The asset-mapper-build-bundle dispatches a BuildEvent so the sass-bundle and the tailwind-bundle can hook into the process with their own defined listener. We could define some default priorities (PRE_PROCESS, PROCESS, POST_PROCESS) to trigger the listeners in the appropriate order.

The first issue I encountered is that the location of input and output files are defined at the bundle configuration level. This makes difficult to use different locations depending on how the build process is triggered (the original bundle command vs the central build pipeline). Here I see two options:

  • We could prepend some configuration in the central bundle to smartly set up the appropriate paths. The drawback is the central bundle should be aware of potential bundles that could hook into the build process.
  • We could allow modifying the input/output paths in each *Builder::runBuild() calls. Then pass the information to the next stage in the event object (not sure if both paths would be useful). The drawback is we have to modify the design of Sass and Tailwind builders, and maybe we'll need an additional interface.

Does it look reasonable/possible to have a watch mode for this tool? I'd personally love it, but I struggle finding a good way to implement a such feature.

@WebMamba
Copy link
Contributor

Hey @squrious. I am not sure if an event-based papeline in the right approach here. Because I think we want everything to run in parallel. So to have one main Process that run all the others process from the different bundles in parralle.
Here I made a small Bundle to try an implementation: https://github.com/WebMamba/AssetMapperBuilderBundle

@squrious
Copy link
Contributor

Hey @squrious. I am not sure if an event-based papeline in the right approach here. Because I think we want everything to run in parallel. So to have one main Process that run all the others process from the different bundles in parralle. Here I made a small Bundle to try an implementation: https://github.com/WebMamba/AssetMapperBuilderBundle

I agree that using tag injection is more intuitive, and allows to control the process from the main build loop, which is not so easy with an event system.

But I'm not sure we always want to run Sass and Tailwind in parallel. You want Sass to produce a pure CSS file before Tailwind tries to process it, at least for the first run and when hooking into the PreAssetsCompileEvent from AssetMapper.

Having the process running in parallel could be nice for a watch mode though.

@lukepass
Copy link

Hello, so as of today it's not possible to use SassBundle along with TailwindBundle correct? That's because they compete for the same file to build?

I also tried giving tailwind the SASS path:

symfonycasts_tailwind:
    input_css: '%kernel.project_dir%/assets/styles/app.scss'

But then I get this error:

Unknown word
You tried to parse SCSS with the standard CSS parser; try again with the postcss-scss parser

That's because the tailwind parser doesn't know how to process the SASS file. I also tried giving tailwind the SASS output file:

symfonycasts_tailwind:
    input_css: '%kernel.project_dir%/var/sass/app.output.css'

But it does nothing.

How can I do to use Tailwind along with SASS and AssetMapper? Is it a bad practice?

Thanks.

@WebMamba
Copy link
Contributor

What do you mean by it does nothing ? The second solution should be the way to go

@lukepass
Copy link

With "it does nothing" I mean that the generated CSS file in the website (the one exposed in the browser) is the elaborated SASS file but with the @tailwind directives becase it's not processed by the Tailwind build.

In this other issue @squrious wrote a working solution: SymfonyCasts/tailwind-bundle#49

@WebMamba
Copy link
Contributor

WebMamba commented Apr 1, 2024

To give you all the context: At first, we thought that this central "build" bundle was needed because of Sass, Tailwind, and Typescript. But then we changed our mind for multiple reasons, first this build bundle looks like we are rebuilding webpack but in PHP, second we believe that people should now stay as close as possible to web standard so pure Javascript and pure CSS. Why do you need Sass? variables? nested? calculation? Those three reasons are now natively possible in CSS

@lukepass
Copy link

lukepass commented Apr 2, 2024

Thanks for the response! I know that recently CSS has improved a lot and can now do many new things. I also read the article linked in the bundle documentation.

In our case, however, our front-end developers have produced some mixins, imports and many other tools over the years that depend on SASS. Unfortunately, as you may understand, it's not as easy as stopping using it from one project to another.

That is because we are trying to update the workflow but keep both SASS and Tailwind CSS.

EDIT: I also found this article useful.

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

No branches or pull requests

4 participants