The Symfony Finland site has an article posted introducing you to Symfony Encore, a tool that makes it simpler to manage frontend libraries and dependencies via Webpack.

Symfony Encore is a wrapper for the JavaScript module bundler Webpack. Webpack is used to manage Front End assets like JavaScript, CSS and image for browser consumption, often with conversion step from a source format like SASS. Encore provides an opinionated way to add Webpack to your Symfony projects.

[...] Earlier this year I experimented with sharing a state object with Symfony and different front end tools. Recently I ported the Symfony 3 application to Symfony Flex. Now I will continue the evolution of the app by adopting Symfony Encore to the project.

The article briefly introduces Encore and what functionality it provides before getting to the installation (via yarn) and configuration that it installs by default. The post then goes through the setup of SASS, using assets in your pages and running builds.

Fabien Potencier (creator of the Symfony framework) has a new post on his site continuing his look at Symfony 4. In this latest article he looks at some of the best practices to use in the next major release of the framework based on some of the architectural changes coming down the line.

Any major version of a project is an opportunity to revisit its best practices. Modernizing them. Adapting them to the project's new features. Symfony 4 is no exception.

He breaks it up into a few different sections offering tips around each, just to get you thinking about the path ahead with v4 releases:

• Standardization first (using more standard tools)
• Bundle-less Applications
• Environment Variables
• Unified Web Front Controller
• Makefile
• Assets Management

Each item includes a description of some of the changes coming and what behaviors you'll need to modify to make life smoother in the Symfony 4 transition.

The SitePoint PHP blog has a new tutorial posted introducing you to Elixir, the "Laravel way" of working with assets in your application and making it easier and more unified.

In today’s web applications, we use a wide variety of tools to speed up the development workflow while keeping the code base as lean as possible. [...] One such type of tool are preprocessors for CSS and JavaScript. [...] Besides preprocessors, there are also many tasks we as developers often have to do, including linting JS files, testing, concatenation, minification, just to name a few.

All this led to the creation of JavaScript-based task runners like Grunt and Gulp. [...] Gulp syntax is clean and easy to use, but there’s always room for doing things the easier way. Laravel 5 introduced Elixir: a Node.js based tool developed by Jeffrey Way, which manages our Gulp tasks the easy way.

They start with the requirements you'll need to get Elixir up and running, including Node.js and Gulp itself (it's a "frontend" for it, not a replacement). They talk about where Elixir assumes your assets will live and some examples of:

• Compiling Less files
• Compiling CoffeeScript files
• Compiling multiple files at once
• Using different source and output directories
• Concatenation files

...and much more. They also show how to perform Jade->Blade compilation for templating and how to configure Elixir to match your needs. The post ends with a more "real world" example with a full site structure, how to run the tasks and some more advanced topics (like custom tasks and using the assets in Blade templates).

Konrad Podgórski has a recent post to his site with his suggestion of a better way to deal with assets in Symfony 2-based applications with the help of some other tools, namely NodeJS, Bower and GruntJS.

I will explain how to work with assets in Symfony framework without having to use Assetic Bundle at all. [...] The process will be really fast and easy to understand even if you never used software listed here. However if you experience any problems do not hesitate to ask for help in comments. Post is quite long because it contain a lot of different configs but don't run away just yet. They are ready to copy & paste.

The setup will download the needed dependencies, merge and minify JS/CSS files, copy font files to the right place and deploy it all to an S3 bucket. He first walks you through the installation of the three tools complete with the commands and configurations to get them all integrated. With those installed and working, he then gets into three "scenarios", the steps in the process to build and deploy the completed version:

• Download latest jQuery, Bootstrap, Font Awesome with Bower and copy the only necessary files to web/assets/*
• Download dependencies with Bower, copy necessary files to web/assets/*. Then minify javascript and stylesheet files.
• Download dependencies with Bower, merge them with your custom css and js files, then minify.

Finally, he includes the steps you'll need to follow to get the whole thing deployed out to S3 (or a CDN). In the next part of the series he'll continue the process and look at things like LESS/SASS, watching for changes in assets and how to use RequireJs.

On the PHPClasses.org site today there's a new post showing how to install more than just PHP packages with Composer including things like Javascript, CSS and image files.

By default Composer installs all package files under the vendor directory. If you want to install asset files in the Web document root directory, you need to resort to another solution. This Asset Manager package is a plugin that extends Composer to install any package files outside the vendor directory. Additionally, it can also read the user names and passwords from a configuration file, so you do not have to enter them every time Composer retrieves packages from repositories that may require authentication, like PHP Classes and JS Classes.

Using an asset manager plugin for Composer, he shows how to include an "extra" section into your "composer.json" for the other files. There's also an example of how to implement a custom installation action that, in this case, was used to implement the "extras" functionality. The post finishes up with a look at handling authentication in the Composer requests, using the same tool to parse a "config" section with Basic HTTP authentication information.

On the Zend Developer Zone there's a recent post from Ralph Schindler talking about an update that's been made to the Zend Framework to improve generated testing stubs for Zend_Tool generated projects starting in ZF versions 1.111.4.

At the time of Zend_Tool's initial release, the standard application structure you are familiar with today was just being released as well with Zend_Application. In addition, the testing controllers from this newly standardized application layer, were too, in their infancy. [...] Recently, while Sebastian Bergmann was working on his pet project php-project-wizard, he noticed a few inconsistencies with the stubs that Zend_Tool was generating and decided to send us some recommendations on how to best leverage PHPUnit 3.4+ to test our application's assets.

He walks you through a newly generated project and shows (complete with screenshots) some of the updates that have been made like the new single bootstrap.php file, an updated phpunit.xml, a sample IndexController test and a bit of detail on what the generated tests actually look like.