This is to add the Assetic component to core in preparation for #1751602: Use Assetic to package JS and CSS files
It only adds the component, there are no other changes.
What is Assetic?
https://github.com/kriswallsmith/assetic
Assetic is an asset management framework for PHP.
Assetic is a Symfony component written by Kris Wallsmith, one of the main Symfony contributors.
We are looking to use it to help manage CSS and JS assets (though it can handle images, too).
Assetic can be used to:
- discover assets
- apply filters to assets (e.g. compression, convert SASS to CSS)
- concatenate assets
- write assets to the filesystem
Why would Assetic make sense in Drupal core?
Currently Drupal uses procedural — and difficult to override — code to:
- work out which assets are needed on the page
- group assets together
- compress and concatenate assets
- write assets to the filesystem
Drupal would still need to work out which assets were needed on a page and how to group those together, but by using Assetic for compression and filtering we would not only open the door for other types of filtering to occur — such as converting SASS files to CSS — but we would also avoid having to write custom code to do the same.
Comment | File | Size | Author |
---|---|---|---|
#35 | 1784774.patch | 517.28 KB | RobLoach |
#9 | drupal-add-assetic-1784774-9.patch | 408.63 KB | mcjim |
#4 | drupal-add-assetic-1784774-4.patch | 399.55 KB | mcjim |
#1 | drupal-add-assetic-1784774.patch | 6.06 KB | mcjim |
Comments
Comment #1
mcjim CreditAttribution: mcjim commentedInitial patch.
Comment #2
nod_tag
Comment #3
nod_tag please?
Comment #4
mcjim CreditAttribution: mcjim commentedOriginal patch didn't actually include component… this one should :-)
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedSetting for review by the testbot and others.
Comment #7
mcjim CreditAttribution: mcjim commented#4: drupal-add-assetic-1784774-4.patch queued for re-testing.
Comment #9
mcjim CreditAttribution: mcjim commentedHaving fun, here :-)
Trying a patch using --full-index
Appears to work locally, using git apply, assuming testbot doesn't choke on trailing whitespace:
Comment #10
mcjim CreditAttribution: mcjim commentedComment #11
nod_looks good to me :)
Comment #12
catchI'm happy to add Assetic on a 'use it or lose it' basis, notwithstanding the caveats I posted at #1751602: Use Assetic to package JS and CSS files. However I'd like to take some time to review it a bit closer before it goes in, and Dries usually likes to do the same with new libraries. So assigning to him.
Comment #13
webchickWe're over thresholds atm so we unfortunately can't commit any feature patches. Help with smashing critical and major bugs would be greatly appreciated.
Comment #14
webchickCan we please get an issue summary to describe what the heck this thing is, and why we want it over any other library that does a similar thing? (Doesn't have to be a book, but a couple of paragraphs would be nice.)
Comment #15
mcjim CreditAttribution: mcjim commentedUpdated issue summary.
Comment #16
webchickThanks!
Comment #17
Dries CreditAttribution: Dries commentedI read the issue summary and don't find the justification very compelling or why this is marked 'major'. I'd like to better understand why this is important and what immediate problem we're trying to solve. We already have different ways to get pluggability and this seems to add yet another one. Would love some more details and motivation.
Comment #18
nod_Having that would de facto fix this issue #119441: Compress JS aggregation that has been tagged as "won't fix" because of licensing/legal issues and which is really, really important for frontend performance. That would allow contrib to implement all sorts of things trivially #1751602-1: Use Assetic to package JS and CSS files.
As far as JavaScript is concerned this is the biggest and most important issue for D8. Hence the "major" status. Ultimately this is a tool to fix this #352951: Make JS & CSS Preprocessing Pluggable. Also, Assetic has Twig integration, which could be very much useful down the line. This component is used by other big PHP projects, I was worried about the fragmentation of the pluggability thing too, after some talks with EclipseGc it seems to me that the most similar thing would be text input format. There are Assetic plugins (symphony-style), and Drupal plugins wrapping them to provide UI and configuration for them.
Using Assetic means we can use all of the other Assetic filters/plugins and extend that relatively easily. Before we just didn't have the oportunity to do it. Ask the labjs, headjs or the advagg module maintainers how much they love the D6/7 processing of JS files, I'm pretty sure they'd welcome any kind of pluggability since that means they wouldn't have to take over the whole processing to do what they want.
Comment #19
catchAt the moment, JavaScript processing is just concatenation, and CSS processing is a somewhat buggy regular expression. If you want to make these pluggable, you have to take over the entire rendering output just to replace those bits, they're not pluggable in the sense that cache backends are. There's more to JS/CSS pluggable handling than what Assetic does (i.e. bundling logic and the actual filename and file generation mechanism), but what it does I think we should use it for.
http://drupal.org/node/352951#comment-6532992 is where things currently stand in terms of fitting things together.
Comment #20
nod_Also that's in the mobile goals: http://drupal.org/community-initiatives/drupal-core#mobile and there is some doc in the unofficial initiative page of JS: http://drupal.org/node/1667512
Comment #21
nod_Comment #22
tsi CreditAttribution: tsi commented+1 for Assetic in core, this would make it trivial for contribs like Sasson to compile Sass.
What is needed here ? or how a themer can help testing here ?
Comment #23
nod_The patch probably needs a reroll and Dries need some more convincing or explanations it would seem.
Comment #24
nod_The patch probably needs a reroll and Dries need some more convincing or explanations it would seem.
Comment #25
SebCorbin CreditAttribution: SebCorbin commentedPatch still applies for me
Comment #26
Fabianx CreditAttribution: Fabianx commentedAnother +1 why this is nice to have in Core and allows easy SASS/LESS/CSS Compression/JS Compression/... in Contrib:
It is really easy to add new Filters into the mix, combine with the DIC / Plugin system to register the factory methods and voilá contrib only needs to implement a filter and it is integrated.
Trying to reach @mikeytown2 to chime in here.
Comment #27
nikkubhai CreditAttribution: nikkubhai commentedAlso, please note that Add a CSS preprocessor to core depends on this issue.
Comment #28
jessebeach CreditAttribution: jessebeach commentedmcjim or Fabianx, you two obviously understand how to implement the capabilities of Assetic. Would it be possible to provide example code here for folks reviewing this module that would put Assetic into use? Maybe a sandbox with a simple module implementation in it? That would be über helpful, thanks!
Comment #29
mcjim CreditAttribution: mcjim commented@jessebeach Yes, a sandbox makes sense.
In the meantime, there's an example implementation here: http://drupal.org/node/1751602#comment-6519134 (this issue's patch from #9 would need to be applied first).
Comment #30
mikeytown2 CreditAttribution: mikeytown2 commentedOverall I'm for Assetic in core, I just have a couple of questions; because I don't want to take a step back.
Looking at the diagram in #352951-66: Make JS & CSS Preprocessing Pluggable Assetic and it's plugins will handle aggregate CSS/JS generation; it needs grouping of files in order to work. Seeing how Assetic needs a grouping of files, can I provide my own version of this to overwrite what will be in core? AdvAgg has one of the best *automatic* bundlers out there, and I would like to use it in the future. I've seen other examples on how grouping of files for aggregation is done and AdvAgg is the best IMO because it uses 2 database tables of info when creating the bundles.
Does assetic allow for aggregate generation to happen in the background via http (what AdvAgg currently does)? This would require #1447736: Adopt Guzzle library to replace drupal_http_request() or something like httprl to be in core so we can create non-blocking http requests (httprl was created by pulling code out of AdvAgg). Reason I'm asking this is CSS/JS minification is expensive and sometimes can take several seconds to run. Being able to generate aggregates on demand in the background is a major plus.
How does it handle GPL issues with minification? #1493876: Better GPL compliance when using JS minification - is how AdvAgg deals with it.
I like that Assetic handles minification so that's a big plus. Hopefully it uses a per file cache for JS and tests the output to make sure minification didn't kill the file.
I like that Assetic handles embedding css images in css files (http://drupal.org/project/css_emimage).
Is there some way to turn off Assetic aggregation with a url query parameter or a cookie? I've used this feature in AdvAgg quite a bit to help debug a production issue with CSS/JS.
I like how the example code in #26 looks.
Comment #31
RobLoachApptegic is an API, allowing us to handle assets how we want to handle assets. If we want to have it happen in the background, then we could do that.
It's completely dependent on what Filters you're using. The UglifyJsFilter, for example, has a NoCopyright property, which tells UglifyJS whether or not to leave the first docblock during its processing. If you want to add your own AdvAgg Filter which would so something similar, then it might look something like:
If we want to do something like that in Drupal Core, then we could. The point is that Assetic is powerful and flexible enough to allow such a thing to happen in either Drupal Core or Contrib.
Again, this comes down to how we use it. Assetic is just a tool. How we use that tool is up to us.
Comment #32
cosmicdreams CreditAttribution: cosmicdreams commentedI'm all for this. It seems that we need to update the Assetic included in the patch in #9 to 1.1 and we likely need to reroll the patch.
What other follow-ups do we need in order for this to be a success?
Comment #33
Dries CreditAttribution: Dries commentedLooked at this and we can go ahead on commit this on a "use it or lose it" basis.
The patch needs to be re-rolled though.
We'll re-evaluate the usefulness and code reduction/simplification of this patch before code freeze. We could choose to roll it back if the gains are limited.
Comment #34
Dries CreditAttribution: Dries commentedUn-assigning it from myself.
Comment #35
RobLoachHad to lower our minimum-stability to bring in Assetic 1.1.0-alpha1.
Comment #37
nod_#35: 1784774.patch queued for re-testing.
Comment #38
nod_tests are ok and Dries okayed it :)
Comment #39
webchickWe're also under thresholds atm. YAYYY.
Committed and pushed to 8.x, along with a changelog entry.
Comment #40
cosmicdreams CreditAttribution: cosmicdreams commentedCreated a follow up issue so that we can use the stable version of Assetic instead of a possibly broken / rapidly changing version.
#1812172: Use the currently stable version of Assetic
Comment #41
tsi CreditAttribution: tsi commentedGuys, I have just pushed a working POC of Sasson (D7) using assetic to compile Sass files.
If anyone wants to check it out or even help making it better that would be awesome.
git clone --recursive --branch assetic http://git.drupal.org/project/sasson.git
Just download sasson 7.x-3.x-dev
note: it was only tested on my Ubuntu machine, I expect issues with certain OSes :)
Comment #42
Fabianx CreditAttribution: Fabianx commentedhttp://drupalcode.org/project/sasson.git/blobdiff/59aa4378b9f2df23c1f282...
Here is the diff from #41 for those that are curious how Assetic can be integrated.
Comment #43
tsi CreditAttribution: tsi commented@fabianx - Thanks but that diff is not a very good example - there are a lot of changes there that are not necessary for a simple integration of assetic.
I can produce a better example if anyone is interested but basically what you need is including composer's
autoload.php
(at the begining of sass.inc), then the compilation itself happens at sasson_parse_compass() on the same file.Comment #44
tsi CreditAttribution: tsi commented-- Double posted --
Comment #45
mcjim CreditAttribution: mcjim commentedSee also patch in http://drupal.org/node/1751602#comment-6519134
Work is continuing in http://drupal.org/sandbox/mcjim/1813618
Comment #46
Wim LeersJust for clarification, this issue was about the packager half, #352951: Make JS & CSS Preprocessing Pluggable is about the bundler (aggregator/grouper) half, right?
(We may want to clarify that in the issue titles, no?)
Comment #47.0
(not verified) CreditAttribution: commentedUpdating summary to add more detail.
Comment #48
catchWe're still not using this. #1762204: Introduce Assetic compatibility layer for core's internal handling of assets is critical at the moment but hasn't had any activity for 2-3 months.
Comment #49
hussainwebThis seems to be a duplicate of #2356845: Remove the assetic library.
Comment #50
catch