Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Assetic is not aware of asset dependencies #79

matteosister opened this Issue Jun 24, 2011 · 109 comments


None yet

As discussed here there is a problem with the new implementation of the compass binary.
The problem is that, the cache system, checks the timestamp of the sass file without involving the filter.
So if you have a main file which imports other "subfiles" (a typical situation working with compass) and you never edit this main file you never get a recompile.

The process of check the timestamp of an assetic file should in some way involve the filter to get a complete list of files to check and eventually trigger the recompile by checking all the timestamps.

This issue is related to compass, but I think it should also appear in Sass and ScssFilter and also on any filter that deal with an asset with a tree of subassets


kriswallsmith commented Jun 24, 2011

I've begun work on this in the mtime-aware branch.

is it already testable?


kriswallsmith commented Jun 24, 2011

not yet.

On Jun 24, 2011, at 9:01 AM, matteosister

is it already testable?

Reply to this email directly or view it on GitHub:
#79 (comment)

@kriswallsmith kriswallsmith added a commit that referenced this issue Jul 1, 2011

@kriswallsmith kriswallsmith [GH-79] removed LastModifiedFilterInterface
This is a symptom of a larger issue of asset dependencies that will have to be addressed in a later version.

srosato commented Jul 8, 2011

What's the state of this issue? Seems like it was postponed, were there any difficulties?


kriswallsmith commented Jul 8, 2011

This is not going to make it into 1.0 unfortunately, but it will probably be the only enhancement in 1.1.


kriswallsmith commented Jul 15, 2011

Some open questions:

  • Do filters cascade into an asset's dependencies?
  • How do we differentiate different types of dependencies? (i.e. @import url() vs background: url())
  • This should allow us to apply filters to all images referenced by a stylesheet -- how do we configure that? Based on URL (i.e. \.png$) or something more complex?
  • How will an asset create its dependent assets? Workers (such as Symfony's apply_to) will not fire unless the factory is used.

And probably more...


kriswallsmith commented Jul 28, 2011

See #96 also.

do you think it's possible to use some native ruby implementation (link this) or plain php to parse line by line the sass/scss files?


pkruithof commented Nov 24, 2011

What's the status on this issue? Is it possible to disable caching completely (on development environments of course) until this is resolved?

disable caching could be a good solution....but I don't think there is a "clean" way to do it...
at the moment I use compass normally as a gem for big projects. For small projects with just few hundreds of line of css code you could use a single file....or remember to change something in the main file if you want assetic to recompile...


pkruithof commented Nov 24, 2011

This is not always the case: when doing minor CSS tweaking you constantly have to save two files, where you want to be fast switching between editor and browser. I know that tweaking in an inspector is faster and sometimes better, but even then I still switch between editor and browser regularly.

As for small projects: I'm currently working on a project where I keep the media query specific CSS in separate files, and import them at compile time in media queries, but also without media queries for IE<9. There are other use cases to think of where using imports is much more handy, even though the size is not that large.

Edit: this is a separate discussion for a disable-cache flag, obviously. Let's focus on the main issue here. :)


srosato commented Nov 24, 2011

The workaround I've been using for the past weeks is "double watching" my files. I fire up the compass watch with a config.rb file to watch for scss file changes, and use assetic to watch on compass' compiled css files. This double watching for now is a bit annoying, but works well until assetic can support dependency watch.

@pkruithof I'm using a single file just because of assetic...normally I use only external files, and in my main file I only import things

@srosato So you are not using the CompassFilter..but some css filters (like yui compressor)? It's a shame because compass itself compress css files pretty well....

To me a solution could be: define a list of dependencies given a base file, and assetic should watch all the timestamps.
This could be a quick workaround to the big problem of checking sass files dependencies in php (in ruby it's easy like calling a function)


srosato commented Nov 24, 2011

Yeah I know it's a shame for now, yeah I'm using other filters like CssRewrite and YuiCompressor after compass compiled the css files, but not the CompassFilter for now since the asset dependency watching is a must for me. I wish I had a little more time as I would try to give a hand on this issue by contributing.

I hope that this pr will bring some quick solution for all these problems...

Also waiting for a solution...

+1 on needing a solution for Less

@redemption quick solution waiting for this issue to be closed


if you try it please let me know if it works for you.


schmittjoh commented Mar 2, 2012

also related to #190

@schmittjoh are there any plans to find a solution for all these problems?
I'm really curious to see what direction assetic will take (assets scan, native binary) and how to implement a filter that can trigger the asset staleness check.
I was hoping that inotify could give a solution....but It's not been merged in sf yet.

mrclay commented Mar 30, 2012

My plan for Minify is to have smart assets ("sources" in Minify) that know how to linearize and manage watching the dependency files for changes. Internally they would cache the list of dependencies so getLastModified() could simply get the max() of all the dependencies. getContent would re-linearize everything and cache the new list.

This, of course, bypasses all the questions about how dependency files are treated: they're treated as a single asset, period. I'm not all that familiar with LESS yet, but maybe a similar LessLinearizerAsset could do the same thing for LESS: just process the imports and leave the processing for the filter. If LESS requires distinct files for vars I guess this wouldn't work.

any updates on this one? its a real showstopper.

arcanis commented Jun 19, 2012

Isn't there a way to disable the cache in dev environments ?

@arcanis I don't think it's a solution, but only a workaround...

arcanis commented Jun 20, 2012

Didn't say it was a solution. But until we found a solution, it would be great to at least have a workaround.

And actually I think it could be a solution. In a dev environment, why using a cache ?

@arcanis because something has to be cached I think. Or you end up waiting for 25 secs for every request. Anyway, don't know if there is a way, and never tried it.
If you find a way and it works without performance issues let me know.

any updates? would be nice to find a solution


fran6co commented Aug 13, 2012

I made #259 to fix this issue, but still pending approval. =/

I really would love to see this fixed.

@k0pernikus do you use compass? or sass only?

@matteosister I use both compass and sass.

check https://github.com/matteosister/CompassElephantBundle
it uses directly the compass binary so everything works as expected...

FYI, a little workaround would be to use something like the following:

watch -n 1 touch basefile.sass

bakie commented Oct 26, 2012

What is the status on this ? Trying to use it for sass files but not going to use it if the imports don't get compiled when changed.


xzyfer commented Oct 26, 2012

We've solved this issue where I work by using a non-persistent asset cache. Unfortunately this means we're essentially rolling with no cache. It's slightly better than rolling with no cache at all since we're able to have a consistent interface.

@see #317 for my implementation of this for you own work.

For those using the AsseticBundle in Symfony2, you can use enable this non-persistent cache by setting assetic.filter.cache: <namespace/class> in your parameters_dev.yml

bakie commented Oct 26, 2012

Did you mean assetic.cache.class: Assetic\Cache\ArrayCache This works for me. Thanks!


xzyfer commented Oct 26, 2012

Yes I did, my apologies I was trying to recall from the top of my head.

On Saturday, October 27, 2012, stephaneb notifications@github.com wrote:

Did you mean assetic.cache.class: Assetic\Cache\ArrayCache This works for
me. Thanks!

Reply to this email directly or view it on GitHub.


Michael Mifsud

T: twitter.com/xzyfer | G: gplus.to/xzyfer

ConneXNL commented Dec 3, 2012

This doesn't solve the assetic:dump --watch during development, does it?

arcanis commented Dec 27, 2012

Hm I get an error "Unrecognized options "cache.class" under "assetic"" with dev-master, is it the correct property ?

[edit] Nevermind, it has to be in property.yml, not in config.yml


stof commented Dec 27, 2012

@arcanis You have to change the assetic.cache.class DIC parameter, not a setting in the semantic configuration of the bundle

arcanis commented Dec 27, 2012

@stof Yep, I figured it out few seconds before your post. Thanks !

igorpan commented Dec 30, 2012

I tried using assetic.cache.class solution but no avail. I still need to alter my main file (add whitespace or something) and only then will it recompile it with imported file changed.

Then I checked if "assetic.cache.class: Assetic\Cache\ArrayCache" has effect at all, so I changed it to invalid value "assetic.cache.class: Assetic\Cache\SomethingRandom" and I got an error in CSS files which means it has effect but it doesn't work for some reason.

Strangely enough, when I returned parameter to "ArrayCache" class, it updated my CSS files with new values. Any ideas on this?


mpdude commented Feb 20, 2013

How does the ResourceWatcher component (Symfony PR 4605 blocked by Symfony PR 4619) relate to this?

Based on that, we could configure dirs, files and patterns to watch (per filter or asset?) and expire the asset cache whenever there are changes.

There can always be resources used but "hidden" behind filters and Assetic can't figure those out. A manually configured "watchlist" is not as bad as having to touch "main" asset files every time a "hidden" file changes.


stof commented Feb 20, 2013

@mpdude it has nothing to do with this. The issue here is to determine what the resource are.

The ResourceWatcher component is about running an action as soon as one of the resources changes. It won't help if you are missing some resources in your list. Thus, Assetic itself is not doing any resource watching (which supposes a long running process doing the dump regularly).
The only part which could relate to the ResourceWatcher component is the implementation of the --watch option in AsseticBundle's dump command (which is currently doing the watching itself with some Assetic specific code).


mpdude commented Feb 20, 2013

I was thinking about manually configuring a set of directories, files or globs as the what, since Assetic cannot figure that out itself. ResourceWatcher looked like a good approach to check this set for changes, additions and removals of files.

But if I got you right, ResourceWatcher will be useless on a per-request level (the AsseticController feature)?


stof commented Feb 20, 2013

@mpdude the goal in this issue is precisely making Assetic able to figure what (because finding other files included when applying the less filter for instance is possible with the source). There is some experiments about the way to integrate this in Assetic already (latest one is #362).

The ResourceWatcher is not about finding resources but about knowing if the known resources have changed and to trigger an action as soon as it happens. Assetic does not need it as it is already able to figure if its resources have changed.

@kriswallsmith : assetic is aware of such dependencies now right? or is this something else?


kriswallsmith commented May 17, 2013

Please open additional tickets for any asset-dependency related issues or requests.

arcanis commented May 17, 2013

@kriswallsmith Not sure to understand, is this issue closed as 'wontfix' or 'solved' ?


stof commented May 17, 2013

@arcanis as "should be solved"


kriswallsmith commented May 17, 2013

This is partially implemented in 1.1.

arcanis commented May 17, 2013

Ok, thanks :)

gponsu commented Jun 4, 2013

Really still not working. I'm using symfony 2.3.0 with Assetic 1.1.1.

Thank you very much! :)


kriswallsmith commented Jun 4, 2013

@gponsu please be more specific.

gponsu commented Jun 4, 2013

Sorry, my English is very poor. First, I appreciate the great work you do to build Assetic, thank you very much. My problem is with the imports. Do not update the changes I make in the subfiles.

I thought that was resolved in version of Assetic 1.1. But I'm using Assetic 1.1.1 with Syfmony 2.3.0 and does not work.


kriswallsmith commented Jun 4, 2013

@gponsu You're very welcome! What filters are you using?

gponsu commented Jun 4, 2013

I'm using compass, this is my setup:

    cssrewrite: ~
        jar: %kernel.root_dir%/Resources/java/yuicompressor-2.4.7.jar
    sass:       ~
        plugins: [susy]
        no_line_comments: true
        style: "nested"
        images_dir: %kernel.root_dir%/../web/bundles/gestion/images
        generated_images_path: %kernel.root_dir%/../web/images

The only problem is with the imports of the subfiles, which does not show me the changes. I tried to clear the cache but not updated.

The only way is to comment on the import line and save. After uncommented it and come back to save. And then it shows me the changes.

Thank you very much for your time! :)

igorpan commented Jun 4, 2013

@gponsu You could alternatively run compass watch and import .css files instead. Compass will automatically recompile .css when any of source files is changed. In that case you should disable compass and sass filter in assetic.

It isn't as elegant as using compass in Assetic but it works

@igorpan @gponsu I created a bundle that does it automatically. Check it out.

gponsu commented Jun 4, 2013

@igorpan Thank you very much, is the option I used before. But as I saw that the error was fixed, try again Assetic and saw it was not working for me.

Thank you very much! :)

mahono commented Jun 11, 2013

It still does not work using node less. When I edit files which are imported assetic does not notice anything.


data219 commented Jun 12, 2013

I might have found a/the issue with imported files (at least in the assetic) filter....
if you dump the list of filennames/-pathes SassFilter::getChildren() computes and checks for existence to find an imported file within one of the fallback paths (or the source files path) you will see that the possible needles are computes the wrong way if you refer to imports residing in a sub-folder.

@import "base/screen" results in this 4 needles that are searched for in each directory:

  • base/screen.scss
  • base/screen.sass
  • _base/screen.scss
  • _base/screen.sass

as far as I understand SASS (not a FE guy, enabling the assetic stuff for your FE-devs here) that should rather be

  • base/screen.scss
  • base/screen.sass
  • base/_screen.scss
  • base/_screen.sass

This is why "base/_screen.scss" is not found in our scenario what breaks the CacheBustingWorker in the long way.

The mistake is to put the underscore in front of the whole reference where the reference needs to be split into path and filename first, prepend the underscore before the filename and put it back together.

Sorry, no test or fix yet, only to infomation sharing. I might not get the time to work on a fix on the short term since we might have found a workaround (dont use the underscored names files) that works for our overdue project....


mpdude commented Jun 13, 2013

@data219 This really looks like a problem. I think it would be better if you opened a dedicated issue for it.


data219 commented Jun 13, 2013

Opened pull request #453

I still have a problem with less files @import and asset cache. This issue is semi-closed but the solution is not clear. How to handle asset depencies without turning out the cache entirely ? (without using a separate less compiler and including only css files with assetic)

I'm using assetic v1.1.1 with sf 2.3

Like @mahono i'm using node less compiler

I'm having the same issue as @mahono, using node less module with the following filter configuration (AsseticBundle):

    debug:          %kernel.debug%
    use_controller: false
        cssrewrite: ~
            node: %node_bin%
            node_paths: [%node_lib%]
            jar: %kernel.root_dir%/Resources/java/yuicompressor-2.4.7.jar
            jar: %kernel.root_dir%/Resources/java/yuicompressor-2.4.7.jar

My styles.less is being included in the base template like so...

{% stylesheets '@AcmeBundle/Resources/public/less/styles.less' filter="less,?yui_css" %}
    <link rel="stylesheet" type="text/css" media="screen" href="{{ asset_url }}" />
{% endstylesheets %}

and it looks like this...

@import "reset.less";
@import "fonts.less";
@import "variables.less";
@import "main.less";

Whenever a change is made in one of the imported LESS files, assetic isn't re-compiling the LESS as it should be.

rdohms commented Sep 4, 2013

Is there any progress on what @jameshalsall mentioned?

Not sure if this was actually fixed for Sass or not ... ?

chadian commented Sep 30, 2013

If in reference to SASS not updating compiled css in dev for @import files then it still doesn't look like it's still not working.

{% "@SngAssetBundle/Resources/assets/css/main.scss" %}
    <link rel="stylesheet" href="{{ asset_url }}" />
{% endstylesheets %}

and in main.scss:
@import "modules/header.scss";

Make a change to header.scss and the change is not reflected on the dev environment.
Could watch the sass with compass or guard, but I've opted for what was mentioned by @CraigMason:
watch -n 1 touch main.sass
Which I'm guessing forces Assetic to think the file has been modified (every second in the example, change time as necessary), so it does a full re-render on the SASS.

Maybe I'll get around to checking out the complimentary bundles that fix this issue.

rdohms commented Oct 2, 2013

Why is this bug "closed"?


stof commented Oct 2, 2013

@rdohms Because the support of asset dependencies has been implemented. Some filters are not using it yet while they should (PRs are welcome to update them), but the feature is there. See the first few comments after closing

rdohms commented Oct 2, 2013

@stof I would love to do PRs but i'm at a complete loss of understanding what can/should be done and where. Lack of documentation.


stof commented Oct 2, 2013

@rdohms See #362 for the PR implementing it

I will try and take a look at this for the LESS filter

On Wed, Oct 2, 2013 at 3:15 PM, Christophe Coevoet <notifications@github.com


@rdohms https://github.com/rdohms See #362https://github.com/kriswallsmith/assetic/pull/362for the PR implementing it

Reply to this email directly or view it on GitHubhttps://github.com/kriswallsmith/assetic/issues/79#issuecomment-25541819

@jameshalsall - have you had a chance to look at this yet?

As a workaround for now, for Symfony 2.3.5, we changed Assetic 1.1.2: https://github.com/integritystl/assetic/commit/ac9ffa90583c667d95f88817748b80b104da741b and changed the Symfony AsseticBundle: https://github.com/integritystl/AsseticBundle/commit/1df175af1ad698de5812a230b609973cf421d451

@stof - What's the best way to go about fixing this as opposed to the workaround we've made above? Should we make LessFilter.php implement HashableInterface and provide a hash function based on lastModifiedDate? The AssetManager in Symfony already has the lastModifiedDate based on all imports of the parent asset, but the filter itself has no way to get that without finding all of the children all over again. I can't think of a clean way to make a hash function on LessFilter.php get the information it needs without doing work twice.

Any guidance would be appreciated. Thanks!

arcanis commented Oct 5, 2013

If you want to prevent multiple execution, can't you cache the results based on ´$content´ hash (md5 or whatever) ? This way you will keep a reference over previously computed dependencies.

@natebundy still haven't got around to this yet, other projects are pretty busy but I rely on it for one of them so will try get round to it

fmosca commented Jan 13, 2014

any news on this? I'm using the scssphp filter and imports are still ignored. If assets dependencies aren't implemented yet for this particular filter, can somebody point me out to any doc or example about how to implement it? I'm more than willing to present a PR.
@natebundy I'm using symfony 2.3.9 and assetic 1.1.2, can you elaborate on the workaround, if possible, as it doesn't seem to work for me...


@fmosca Our workaround simply tacks on the last modified date to the cache key. $lastModified in AsseticController is already getting last modified based on the child LESS files (LazyAssetManager.php getLastModified), so tacking it on to the cache key makes the cache key change when any of the children are changed, forcing it to invalidate the cache and recompile.

There may be a difference between the way the Less filter (we're using LessFilter with nodejs) and scssphp filter are behaving.

I'm not sure if the latest last modified or a hash of the file contents would make the most sense long-term, but last modified works as a nice band-aid for the time being so our devs aren't tearing their hair out every time there are changes in LESS files. (We're now using Symfony 2.4.1 with symfony/assetic-bundle v2.3.0 and kriswallsmith/assetic v1.1.2 and the workaround is still working)


lalop commented Jan 14, 2014

@fmosca I've ever made a pr #504 It's not perfect but that extracts the children.

An example of how to get the supposed fixes working this less would be appreciated. (ie. config settings and filter settings) I've been tinkering for days and this is still an issue.

I still having problems to use sass in my project; the css files do not recompile with every request in development environment (in this case. scss files).

Is this issue solved for SASS?

Here is my config:


    debug:          "%kernel.debug%"
    use_controller: false
    bundles:        [ "SystemBundle" ]
        cssrewrite: ~
        sass: ~
            bin: /usr/local/bin/compass
            apply_to: "\.scss$"
            jar: "%kernel.root_dir%/Resources/java/yuicompressor.jar"
            apply_to: "\.css$"
            jar: "%kernel.root_dir%/Resources/java/yuicompressor.jar"


    {% block stylesheets %}
        {% stylesheets output='/css/main.css'
        <link rel="stylesheet" href="{{ asset_url }}" type="text/css" media="screen" />
        {% endstylesheets %}
    {% endblock %}


// Utilities
@import "helpers/variables";
@import "helpers/functions";
@import "helpers/mixins";
@import "helpers/placeholders";

// Base
@import "base/normalize";
@import "base/typography";

// Layout
@import "layout/layout";
@import "layout/header";
@import "layout/footer";

I am using Assetic 1.1 under Symfony 2.5.*


stof commented Aug 20, 2014

the issue is resolved for the SassFilter, not for the CompassFilter which is the one you are using. See #640 for the implementation for CompassFilter

lokhman commented Jan 29, 2015

@stof the issue doesn't seem to be resolved yet for SASS/SCSS.

sonu27 commented Feb 16, 2015

@stof We are still having this issue for SCSS files.

However, if we disable the asset controller, and watch the files, it does detect changes from @imports.

            bin:      "/usr/bin/sass"
            no_line_comments: true
            apply_to: "\.scss$"
            http_path: /
            images_dir: %kernel.root_dir%/../web/images
            generated_images_path: %kernel.root_dir%/../web/images
            http_generated_images_path: /images

kniziol commented Feb 18, 2015

@stof Not working for me. Details below. What should I do now?


# This file is auto-generated during the composer install
    compass_bin_path: /usr/bin/compass
    nodejs_bin_path: /usr/local/bin/node
    uglifyjs2_bin_path: /usr/local/bin/uglifyjs
    uglifycss_bin_path: /usr/local/bin/uglifycss


# Assetic Configuration
    debug:          "%kernel.debug%"
    use_controller: false
    bundles:        [<all required bundles>]
    #java: /usr/bin/java
        cssrewrite: ~
        sass: ~
            bin: %compass_bin_path%
            node: %nodejs_bin_path%
            bin: %uglifyjs2_bin_path%
            node: %nodejs_bin_path%
            bin: %uglifycss_bin_path%


{% stylesheets output='css/homepage.css' filter='compass, ?uglifycss'
    <link rel="stylesheet" type="text/css" href="{{ asset_url }}" />
{% endstylesheets %}


@import 'common';

.main-content {


// Variables: colors
$font-color: #4e4b4b;
$dark-blue: #0471CC;


    "require": {
        "php": ">=5.3.3",
        "symfony/symfony": "2.6.*",
        "doctrine/orm": "~2.2,>=2.2.3",
        "doctrine/doctrine-bundle": "~1.2",
        "twig/extensions": "~1.0",
        "symfony/assetic-bundle": "~2.3",
        "symfony/swiftmailer-bundle": "~2.3",
        "symfony/monolog-bundle": "~2.4",
        "sensio/distribution-bundle": "~3.0",
        "sensio/framework-extra-bundle": "~3.0",
        "incenteev/composer-parameter-handler": "~2.0",

liviucmg commented Jun 7, 2015

Can confirm that using use_controller: true does not detect changes of @import-ed assets, while use_controller: false + app/console assetic:watch does work.

I also tried using latest dev-master of Assetic, but nothing changed.

sonu27 commented Jun 8, 2015

@stof @kriswallsmith Could this issue be reopened please?

perk11 commented Sep 4, 2015

Experiencing exactly the same issue as @liviucmg here

Going off on a tangent here. I'm guessing many people will be using Gulp or Grunt. Adding the ability for assetic:dump to target a single asset will give a lot of people the ability to use those tools to watch for changes while still having assetic work its magic on the individual assets themselves.


use Gulp to watch: Resouces/public/sass/**.*,

use assetic (from within Gulp) to dump: Resources/public/scss/main.scss

It will also eliminate the need to re-invent the wheel inside assetic/symfony when there are great tools already available. (Gulp, Grunt)

Same here. Watching imported assets does not work.

Also I'm not interested in installing Gulp or whatever for just watching the SASS files. I bet there are also others thinking the same. So no need to re-invent the wheel but fixing the issue would be great :-)

henrypenny commented Dec 12, 2016 edited

@moezkorkmaz the issue is that Assetic would need to re-invent the wheel by resolving sass imports. Something that is done by libsass if you use gulp.

From the gulp-sass page (https://www.npmjs.com/package/gulp-sass):

gulp-sass is a very light-weight wrapper around node-sass, which in turn is a Node binding for libsass, which in turn is a port of Sass.

There are a couple of libsass wrappers for php:


Perhaps these would be a starting point. But it would involve adding an extra php extension to your environment.

I would suggest to get rid of assetic and php to manage assets. In my opinion it's not worth it. Better go with javascript and a build tool like webpack or gulp.

MatthiasKuehneEllerhold commented Dec 13, 2016 edited

@henrypenny As far as I know Assetic knows about asset dependencies. The sass filter parses the file and resolves all imports in it. See ScssphpFilter::getChildren()


mpdude commented Dec 13, 2016

Forget about Assetic, come up with a build process using front end tools like Gulp and get things like CSS livereload for free. Plus a performance boost on development as Assetic makes Symfony really slow, at least five years ago when I last checked.

@mpdude Is this your opinion as a maintainer or as an user?


stof commented Dec 13, 2016

@MatthiasKuehneEllerhold my recommendation as one of the Assetic maintainers is indeed to switch to a stack built directly using frontend tools if it can fit your workflow.

There are 2 different ways to use Assetic:

  • using only tools written in PHP. But the issue is that most of them are ports of the original tools written in other languages (Node.js for most of them nowadays, but also Ruby or Java for older ones), which are badly maintained and often far behind the original project in term of features because the original project moves very fast.
  • using Assetic filters calling the original tool directly. But then, Assetic is far behind regarding support for configuration settings (as we just don't have resources to update these filters each time one of these projects adds a new option), and it brings no benefit compared to using the tool in a frontend stack (where the integration is generally much better as it is supported by the tool maintainers themselves).

In the second case, my recommendation is clear: stop using Assetic and switch to Gulp or equivalent.
If you are in the first case, consider whether you can switch to the second case, and keep using Assetic otherwise.

Assetic was written at a time available tools were mostly Java and Ruby ones, with no easy way to build a stack combining them automatically. But the ecosystem has evolved a lot since 2011.


mpdude commented Dec 13, 2016

@MatthiasKuehneEllerhold I dug deeper into Assetic a few years ago, also trying to solve this particular issue. I had to learn that it is not worth the hassle and so I can only endorse what @stof says.

As I was mostly using SASS and cssrewrite, the transition over to Gulp was pretty straightforward. I should have a how-to presentation lying somewhere around (in German), email me when you're interested.

MatthiasKuehneEllerhold commented Dec 13, 2016 edited

Now thats a grim outlook. We just started a new project and integrated assetic in it. I was worried that it might be abandoned due to 100+ open PRs and no commit for half a year but all the other options weren't as good. I really liked the ZF integration...
Thanks for your opinions!


stof commented Dec 13, 2016

@MatthiasKuehneEllerhold lots of opened PR are about adding new filters dealing with more Node.js tools. And as I had few time to dedicate to Assetic these past months (and @kriswallsmith even less than me), adding more filters we don't use and we would have to maintain is not something we rushed about, especially given that we know that they would become outdated a few weeks later when the tool adds new options.

@MatthiasKuehneEllerhold @stof I had some success writing my own assetic filter some time ago.


Its basically a copy and paste of the cssrewrite filter. But it handles @AppBundle:css/mycss.css references and doesn't require assets:install --symlink.

From memory it was working reasonably well with my use case. I could set up watches in grunt or gulp and get assetic to dump them. But that approach dumps everything at once - css, images, js - which is far too slow.

I wanted to be able to target a single sass file like so:

`app/console assetic:dump '/style.scss``

But I didn't get that far.

Targeting single files with assetic:dump would allow assetic to remain lightweight and let other frontend tools do the heavily lifting. But we could still have the benefits that assetic offers with regard to managing frontend resources from multiple bundles etc.


stof commented Dec 14, 2016

Well, I don't see the benefit of gassetic compared to using gulp directly. Replacing the Gulp config file (which can contain code) with a YAML used to generate it seems to me like it may suffer from the same limitations about tool support (but I may be wrong as I just looked at it quickly).
Thus, it looks like it would have to replace the content of the Twig template when running the command, which looks like a weird integration (and would not allow benefiting from the Symfony Asset component features like cache busting). I think referencing the dumped asset directly rather than adding the gassetic layer.

henrypenny commented Dec 14, 2016 edited

@stof how hard would it be to modify assetic:dump to target a single asset - or better still a list of assets?


stof commented Dec 15, 2016

Well, there is some challenge here, because asset names in the manager are truncated sha1 hashes by default (and I doubt many people are naming their assets explicitly in Twig, as I'm not even sure we ever documented how to do it). So you would have a hard time passing the argument.

IMO ideally one would reference assets like this:

app/console assetic:dump @AppBundle:sass/style.scss.

How does assetic resolve @AppBundle:sass/style.scss when templates are parsed?
Surely this logic must already exist?

note: I had some success referencing sass assets like this in an experimental copy of cssrewrite I did a while back.

Do you think this conversation deserves its own issue?


stof commented Dec 16, 2016

@henrypenny the issue is that this is not the asset being added in the manager (and so dumped). What you need is to reference the {% stylesheet %} tag added in your template, not a small part of its configuration.


stof commented Dec 16, 2016

and yes, please move this to a dedicated issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment