It’s time to talk about what happens after our framework is made. Writing code is just the beginning. The hard part is getting people to use it and keeping it fresh and useful.
I think it would help to frame this part of things by talking about what I would still like to do to our framework and example application before I’d be happy putting it out into the world…
Finishing Touches
Every popular framework has a starter kit. These are the kinds of projects you can copy, clone, or otherwise install, in order to see how the code works. These starter kits serve as a kickoff point for new applications. They should be helpful and easy to understand.
With that in mind, here are some things I’d like to add before releasing it to the world.
#1: Helpful Home Page
Making the home page helpful. The first page a user sees should reassure them that things are set up correctly, for them to be able to start developing. There should be links to documentation and other resources they might find useful (like hosting and debugging options).
Laravel’s helpful home page
Starting with a new framework can be a daunting task, so this makes a huge difference. There’s no required configuration to “get things going.” If you want to start using models (or other database functionality), then you need to set up a database.
Perhaps this could be a little easier by configuring SQLite by default. Then new users wouldn’t need to configure anything to be able to use 80% of the framework’s functionality.
#2: More Examples of Functionality
We’ve built so much functionality, but very little of it is demonstrated in the example application. There are some small examples of working with the session and cache. Not much else.
Even if the examples were commented out, it would still be useful to show the appropriate time and manner in which to do common things. We could show how to send emails or do something in a queue or how to put files in a remote filesystem.
This is where tutorials and good documentation do a lot of heavy lifting. Speaking of which…
#3: Good Documentation
Good documentation (or lack thereof) is one of the first and biggest gripes other developers will have with your framework. They want to see how the framework can be used, how it can be configured, where it is supported, and what its limitations are.
There’s a huge spectrum your documentation can be on. Laravel is concise and focused on key parts of functionality. The Laravel community (and PHP communities in general) is good at filling in the gaps, in the form of written and video tutorials.
Symfony, on the other hand, has extensive documentation that some may find overwhelming in volume and specificity. I have never had a question about how to use a Symfony component that wasn’t answered by the documentation.
The key is to give enough information for how you expect the component to be used most commonly and have links to good community resources for specialized use, optimization, and extension.
The first PHP framework I used was CodeIgniter. It’s still alive and kicking (at the time of writing), and it was a great influence in my career. Not because it had the best code or biggest community, but because the documentation told me everything I needed to know in order to learn how to use the framework.
CodeIgniter 2 documentation table of contents
More recent versions have done away with the “introduction,” but I guess there are more ways to learn about those topics these days.
#4: Complete Tests
Another big gripe developers have (and rightly so) is when a new framework comes along without a comprehensive and effective test suite. If you want to launch a new framework, make sure you have 90–100% of the functionality it provides covered by automated tests.
You don’t need to test third-party code, but you should test the ways you connect to and use it.
#5: Make Sure It’s What You Want to Do
Building a framework is hard, but it’s the easiest part of the journey. Maintaining a framework for years will take up much of your life, if you do it well.
You are far better off taking many smaller parts from the different frameworks and putting them together into something coherent and useful for your purposes.
Or, better yet, learn how to use a popular and well-supported framework yourself. We’ll talk more about these in the Afterword.
Using Packagist
Throughout this book, we’ve installed many libraries using Composer. These libraries are all hosted on a site called Packagist. If you want your framework (or individual libraries) to be installable through Composer, you need to submit it to Packagist.
If you haven’t already, create an account. If you’re using GitHub to host your code, you may as well use GitHub to log into Packagist.
Signing in with GitHub
Your library needs to have a well-defined composer.json file. I don’t want to go too deeply into the specifics of this, because it’s an art all on its own.
If you’re at this point and want to know how to publish your own packages, then check out a video course like PHP Package Development. It covers details about the composer.json specification, as well as teaching how to properly structure stand-alone Composer packages really well.
The full composer.json specification takes quite a bit of time to understand, and you can find it on the Composer documentation site.
Once you’ve put one together, submit it through Packagist’s submission form.
Submitting packages
Then, you (or anybody else) will be able to install your library through a composer require terminal command. That’s really all there is to it.
Summary
If you remember nothing else about this chapter, let it be this: maintaining a framework is hard work. Building one is a rite of passage and a brilliant way to learn how they work, but it’s a big decision to own a framework. It’s not an easy task.
Hopefully, this chapter has given you a look into some of the challenges that await and things you should consider. I’ll see you in the Afterword of this book.