GitHub now allows a well-known folder for these.

This commit: drop PHP 5.4 should have also changed matrix php setting to 5.5. This caused errors when building on travis:

This package requires php ~5.5|~7.0 but your PHP version (5.4.37) does not satisfy that requirement.

Could this repository be put up on Packagist so I could just type in composer create-project league/skeleton?

would you be open to a PR that replaces references to thephpleague and league with a generic :vendor placeholder? This would make the package more agnostic and serve as a good starting point for all packages.

Since commands diff and patch do not exist on Windows, composer format fails.

GitHub now exposes release information via the site.github.releases Jekyll namespace. Is this something we might want to display on our sites?

https://github.com/blog/1996-releases-metadata-for-github-pages

Shouldn't "docs" be in .gitattributes instead of .gitignore?

This way, the documentation would be available in the repository for everybody to read but it would not be downloaded when the package is required by another project.

For a better understanding, you should describes the purpose of every folder, just like https://github.com/php-pds/skeleton

Detailed description

https://github.com/thephpleague/skeleton#structure

This section contains a typo:

Incorrect: test/
Correct: tests/

Output:

>composer test
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
> phpunit
Could not open input file: <my_project_folder>\vendor\bin\/../phpunit/phpunit/phpunit

Detailed description

PHPUnit 6 wants PHPUnit\Framework\TestCase
but the default file has extends \PHPUnit_Framework_TestCase
so if composer install installs 6 per the composer.json options ~4.0||~5.0||~6.0
then this will break.

Context

Not sure the best solution. The user might not run composer install prior to running the prefill file so hard to fix it during setup.

Possible implementation

Maybe update the docs? I am happy to provide a fix just not sure the best way to go with it.

Your environment

• PHP 5.6

I used the .scrutinizer.yml file of this Skeleton. When I run an inspection on scrutinizer-ci, it times out because of the long waiting for 'external code coverage' which then ends in "Code coverage data is not yet available."
Is there something I did wrong?

All the packages use docs. For example https://github.com/thephpleague/booboo/tree/gh-pages

So it should be part of the skeleton.

Detailed description and context

The package_vendor variable is currently used for both the Packagist vendor name and the PSR vendor name.

I.e. I am using sander-van-hooft as my Packagist vendor name, and SanderVanHooft as my PSR vendor name, sandervanhooft as my github username.

(Yes, that's inconvenient, but it's too late to change now. )

The prefill.php and the markdown document do not make a distinction between these variables, so I end up editing them manually.

How can it benefit other users?

Possible implementation

1. Use separate variables in the markdown files for the vendor: github_username, packagist_vendor, psr_vendor.
2. Find a way to conveniently integrate this into the prefill.php file.

I was wondering what the rational was behind using phpunit instead of vendor/bin/phpunit.
This seems weird to me, especially since PHPUnit is included as a Composer development dependency but may not be available globally.

Detailed description

The file .scrutinizer.yml has a property named fix_identation_4spaces which is not the correct spelling for indentation.

It's not clear if this is a type at the configuration level (.scrutinizer.yml) or at the app that reads the configuration.

Proposal

Correct the spelling or add a comment to indicate that the misspelled word is intentional.

$ composer require guzzlehttp/guzzle

Using version ^6.2 for guzzlehttp/guzzle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - scrutinizer/ocular 1.3.1 requires guzzlehttp/guzzle ~3.0 -> no matching package found.
    - scrutinizer/ocular 1.3.1 requires guzzlehttp/guzzle ~3.0 -> no matching package found.
    - scrutinizer/ocular 1.3.1 requires guzzlehttp/guzzle ~3.0 -> no matching package found.
    - Installation request for scrutinizer/ocular == 1.3.1.0 -> satisfiable by scrutinizer/ocular[1.3.1].

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://groups.google.com/d/topic/composer-dev/_g3ASeIFlrc/discussion> for more details.

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

Installation failed, reverting ./composer.json to its original content.

My suggestion is to drop the composer dependency and use the downloadable phar.

What is a rationale behind creating a separate namespace for tests as seen in tests/ExampleTest.php?

E.g. why one should use League\Skeleton\Test but not League\Skeleton for his ExampleTest?

How that approach is supposed to work for deeper namespaces? E.g. for League\Skeleton\Deep\EvenDeeper

As outlined here, the copyright notice should probably be updated to include contributors.

But in the case of open source, there will likely be multiple contributors, each retaining their own copyright. You might write something like Copyright [year] Alison, Ben, and Charlie, but as the number of developers grow, things will quickly get out of hand. So lets simplify things and just write, Copyright [year] the [project] contributors.

if you want to be super technical, there’s no reason you couldn’t say [project founder] and the [project name] contributors. In either case, just putting the project founder or maintainer is strictly speaking wrong, assuming others have contributed.

How about updating LICENSE.MD to say something like:

Copyright (c) 2016 :author_name <:author_email> and the :package_name contributors

Add Issue and Pull Request templates, to the root folder or to the .github/ subfolder, as explained here: https://github.com/blog/2111-issue-and-pull-request-templates .

The main purpose of this repository - use as template
It may be achieved via Creating a template repository
as you can see for existing repository it just changed setting
Example of template repository
And still this repo may be forked