How to write open-source in PHP 2: Rise value of your package with help of skeleton

This post was updated at February 2021 with fresh know-how.
What is new?

The thephpleague/skeleton is falling behind last 3 years, promoting deprecated practise, so it was dropped. Scrutinizer to PHPStan, ECS added.

After creating a repo, we have to fill it with something useful. Our code! Of course, but we also need some metadata files. What are they for? Is there some prepared code we can use? What are badges for? I will answer all these questions today.

Other programmers who want to use your package are usually looking for long term value. To estimate the value they need to answer 4 important questions.

  1. What is quality of package?
  2. Does it solve my issue?
  3. Is it trustworthy?
  4. How well maintained is it?

Even if you know your code is the best and the cleanest, if they don't trust you, they will never use it.

I will let you think about them a little bit. We will relate with specific files to them in second part of this article.

Use solid skeleton → start solid brand

Now, the first step that can positively influence all the 4 answers is using a skeleton with prepared metadata files. Guys from The PHP League already did the job for you and created a skeleton package.

How to get Skeleton code to your local Repository in 4 steps

  1. Go to repository on Github and click on Clone or download

  2. Then Download a ZIP

  3. Unzip the zip file to your local repository

  4. And push new files to Github

    git add .
    git commit -m "add metadata files"
    git push origin master

Great for start, yet obsolete later

This skeleton is great for start and to learn about metadata files.

But when I create my package now, I just copy the most recent package I made, delete /src and /tests directories and I'm ready to roll. This is because:

What is the Purpose of these Files?

Now we look on every directory and file and how it's related to the 4 key questions. Just to remind you, the end user is interested in:

  1. Quality - What is quality of package?
  2. Usability - Does it solve my issue? Is it easy to use?
  3. Trust - Is it trustworthy?
  4. Maintenance - How well maintained is it?

/src directory



/tests directory

























So that are all files and their purpose.

No time! Fast! Now! → Tell your story with an image

Today people are scanning the text rather then actually reading. That's why badges are so important!

Look on these 2 - what information can we get?

Confusing badge

From Doctrine2 repository.

Well informative badge

What have we Done Today?

What's next?

Happy coding!

Do you learn from my contents or use open-souce packages like Rector every day?
Consider supporting it on GitHub Sponsors. I'd really appreciate it!