The SitePoint PHP blog has a tutorial posted by Younes Rafie introducing the php-pds/skelecton package definition and how it can be used to provide some structure and consistency across your package development.

Looking at the Packagist registry, we can see that most packages follow a pattern, with some small changes to fit their needs, while others have a weird folder structure that takes time to get your head around.

This problem has been solved in different ways by different people. Some frameworks have their own recommendations on how to structure your classes and assets, while others have a skeleton that you can use as a starting point. In this article, we’re going to explore the php-pds/skeleton and use it to build a small package as a demonstration.

He then uses a Laravel package example to show the build up of the package structure (based on the pds/skeleton definition). He goes through each portion of the skeleton structure talking about what they should contain:

• config
• resources
• source files
• tests
• the "public" directory
• bin/ folder
• documentation
• other files like README and LICENSE documents

He also suggests including a guide to contributing to the package and how to use the "validate" command to be sure this and the other items in the structure are in place.

Fabien Potencier has continued his post series covering the next major release of the Symfony framework, Symfony 4. In this latest post he walks you through a quick demonstration of the creation of a new Symfony 4 application including a simple administration system.

Time to test Symfony 4... or at least let's test the experience of developing Symfony 4 projects with Symfony 3.3. Keep in mind that all the tools are in preview mode. Features might evolve over time. I'm waiting for your feedback! The first stable version of Symfony Flex will not be released before Symfony 4 at the end of November 2017. It gives the community plenty of time to discuss the changes I have described in this series of blog posts.

He then walks through the process for creating the application:

• Using Composer's "create-project" to make a new skeleton application
• Setting it up as a git repository
• Defining environment variables
• Registering the framework bundle
• Installing the command line tools

With the basic application set up he then shows how to install the EasyAdminBundle to create the simple administrative interface. He's also created a screencast showing this same process so you can see it all in action.

On the SitePoint PHP blog they've posted a tutorial from author Francesco Malatesta covering his Laravel package building workflow.

Packages are a really important part of the Laravel experience (just like with any other framework). Whatever we need to do, there’s probably already a package for it out there; ready for a composer require to bring some magic in.

Some weeks ago, I had an idea for a new one. I work for AdEspresso, where we have a Symfony FeatureBundle, which handles feature toggling in our projects. It’s a really nice piece of code that we use to release new features only for specific subsets of users. So, I asked myself… why not port it for Laravel? That’s how my Laravel Feature package idea was born.

[...] In this article, I will try to explain how I prepared my development environment for it, and which choices I made when building the package. Not the development of every line of code per-se, but the actual workflow of getting from nothing to a full package.

He starts by talking about a handy addition to an application that can make the rollout of your new package easier: feature flags. He then starts in talking about the Composer configuration of the package and its "skeleton" (default directory and file structure). The tutorial then starts in on the code in the package itself covering the abstraction of domain code and implementing the features including the configuration, Blade template and the matching facade.

The Master Zend Framework site has posted a tutorial helping you create a Docker-based development environment complete with PHP, MySQL and Apache working happily together.

Why in this modern day and age is setting up a development environment still such a complicated process? [...] Why is it still so hard to get one setup that works, that does what you need, and that matches the deployment environment’s of testing, staging, production and so on?

[...] By now our development environments have grown quite sophisticated. But the overhead of both building and maintaining them has increased significantly also. Wouldn’t it be easy if we could set them up, but with only a small investment of time and effort? I think you know where I might be heading with this. You can. Yes, that’s right, you can. Ever heard of Docker?

He then starts in on introducing Docker (for those not already familiar) and how it differs from a VirtualBox/Vagrant setup that's already become quite popular. He talks about "containers" and the role they play as well as an overview of the environment he's going to show you how to create. He then helps you get Docker installed, explains how the containers will work together and provides the Docker YAML configuration for each of them. The docker-compose command is then used to bring the environment up, downloading the containers as needed. The final result of his setup is a set of containers running together to serve up a Zend Framework Skeleton Application.

Loïc Faugeron has posted another in his series of "Ultimate Developer Guides" for a component of the Symfony framework. In the latest part of the series, he looks at the Skeleton component.

In this guide we've explored the main standalone libraries (also known as "Components") provided by Symfony to help us build applications: HTTP Kernel and HTTP Foundation, Event Dispatcher, Routing and YAML, Dependency Injection and Console. We've also seen how HttpKernel enabled reusable code with Bundles.

In this article, we're going to have a closer look at how to organise our applications directory tree.

He shows how to create a new project with the "empty edition", a skeleton for creating a basic Symfony framework with some of the basic boilerplate already in place. He shows the resulting directory tree and creates a new AppBundle for his new development. Initially he put the bundle under the main directory so he then shows how to decouple this and move bundles and libraries out into a src/ directory outside of the main application directory in the skeleton.

In part one of a new series on the SitePoint PHP blog Bruno Skvorc looks at the right way to start a PHP package using a set of guidelines that have evolved recently in well-structured, well-tested PHP packages.

In recent years, good standards for PHP package design have popped up, in no small part due to Composer, Packagist, The League and, most recently, The Checklist. Putting all these in a practical list we can follow here, but avoiding any tight coupling with The League (since our package won’t be submitted there – it’s specifically made for a third party API provider and as such very limited in context).

The list of rules includes topics like having a license selected, using PSR-4 autoloading and having in-depth code comments. Bruno uses these as a foundation and starts in on the creation of a package. He uses the PHP League skeleton structure to create the files and folders for a basic package. From there he updates the contents with details for his Diffbot example and installing other needed software libraries. The rest of the post is broken up into the two remaining steps and examples under each: sticking with the PSR-2 guidelines and planning for the structure of the package.

Peter Petermann has (re)posted an article he wrote about building better project skeletons with Composer and automate the process to make your life easier.

The more you use modern frameworks and the more modular you build your PHP applications, the more likely you’ll use a skeleton (or template) for creating new projects. In fact, most of the better known frameworks provide skeletons for you to bootstrap your application with. Those skeletons are great to get started, but it’s very likely you’ll have your own stack of composer packages that you integrate in each project after a while. Each skeleton will be slightly different, so you’ll likely fork your own. This article is meant to provide you with an understanding on how to build a skeleton that will allow you to automate things as far as possible.

He starts with some of the basics, both in the terminology that will be used in the article and a little bit about projects in Composer. He shows how the Zend Framework 2 project makes uses of a built-in "composer.phar" file to make bootstrapping easier but soon asks how it could be improved. The answer comes in the form of Composer's own "create-project" functionality (with a few additions, like cleanup scripts run after the fact). He then gets into building his own custom skeleton that includes a custom post-create-project cleanup script, templates for static files (README, CHANGELOG, etc) and a basic "composer.json" configuration for the end result.

On his site Fabien Potencier has posted about a feature added to Silex to help make debugging the flow of your application "more fun" - the Symfony web profiler.

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.

Evan Coury has a recent post to his site showing you how to set up and use the ZF2 skeleton and ZfcUser components of the Zend Framework 2.

This is meant to be a short, easy-to-follow tutorial to help you get started with Zend Framework 2.0 and add perhaps one of the most common modules, ZfcUser. By the end of this tutorial, you’ll have a simple ZF2 application with user registration and authentication capabilities.

He breaks it up into a three different steps:

• Getting the skeleton
• Setting up a database connection
• Installing ZfcUser

He also provides some links to other handy resources and libraries you can use to extend the ZfcUser functionality with things like ACL support, two-stage signup and Github authentication integration.

In this new post to his blog, Philip Norton reminds you about a handy feature of PHPUnit, the popular PHP unit testing tool, that can make generating tests for your application simpler - the skeleton class generator.

If you create classes in PHP then you should be unit testing them as much as you can. Setting up unit testing classes for your code can be time consuming and involve a bunch of copying and pasting. Thankfully, PHPUnit comes with a couple of helper functions that allow the creation of unit testing classes automatically, which can save a bit of copying and pasting.

He includes an example of a class named "Spider" and shows both the contents of the class and the resulting test that comes from running "phpunit --skeleton-test" on it. The resulting test has methods for each method in your class and marks them all as incomplete. As Philip notes, this is a good start but should never be relied upon as a test to leave as-is.