2. You are pretty strict on the latest versions - you try to update packages to support PHP 7, now Laravel 5.3. What is the thought behind such strategy? We are indeed quite progressive when setting our minimum requirements. When starting a project, I always like to use the latest and greatest version of stuff. I think all developers enjoy working with the new stuff. Most of the time the newer versions of PHP and Laravel enable you to do stuff more quickly in a more expressive way. Things like the null coalesence operator in PHP 7 or the mailables in Laravel 5.3. Every new package that we create gets born inside a client project. When we feel like we can make something we can reuse ourselves and share with the community the decision is often made to just make a package out of that functionality. The minimum required version for that package is equal to the version the project is using. All our client projects starting with PHP 7 now, so it makes zero sense for us to create PHP 5 compatible packages. Sure, setting the minimum required PHP / Laravel versions so high will hurt the popularity in the short term, but popularity is not our main goal. And I’m sure that in the long run having PHP 7 only packages will work to our advantage.
3. How do you find time for maintaining those packages, in between client work? Do you calculate their hourly price or any other monetary value to support them? We do long term planning at Spatie, but we also have a weekly short term planning meeting. When scheduling out to the coming week we only plan four days. So we have one work day we can be a bit flexible with. Do not imagine that day as like a fixed day, that time is mostly spread out in that week. Sometimes we do client work in that time, because an estimation was wrong, or we need to do some support things. But that time is also used to review/solve issues and review/merge pull requests. Personally I really like working on open source stuff, so I spend some of my free time work on our open source packages as well. I see it both as work and as a hobby.
4. Do you receive a lot of pull requests or issues from the community? Or emails with suggestions? In general, how active is the community in helping with your packages? In the last half year the popularity of our packages has risen and it’s noticeable in both reported issues and number of pull requests. That feedback from the community is really valuable. There’s one package that was very community driven: laravel-fractal. That package is basically a very developer friendly wrapper around The League’s Fractal package. I coded up the basic functionality to I needed myself and tagged that 1.0.0. In the next weeks I almost daily got a pull request adding another great feature to the package. And now it supports almost everything League’s Fractal can do. I think 90% of the code of that package was written by the community. Some of our package users also help out with handling issues. I should mention Nicolas Beauvais here who is helping out handling issues on our medialibrary package and submitting some good PR’s to it.
5. Any favorite package to you personally? Or the one you are most proud of? That would be laravel-medialibrary. That package can associate all kinds of files with Eloquent models. We use it in every project. Because we use it so much it has gotten a lot of love and feel like it’s pretty stable and can handle a lot of use cases now. Another package that I really like, is our menu package. It provides an elegant way to build up complex html menus. It’s written by my colleague Sebastian who, like always, did an excellent job. If you take a look at the code you’ll see that it is very well written. Because I blog and tweet a lot I’m the public face of our packages, but you should know that Seb does quite a lot too. He loves working on the more lower level stuff (the regex package is also one of his). I myself enjoy working on the bigger infrastructure kind of packages like backup and medialibrary.
6. Plans for the future? Do you have a roadmap of packages to build, or update existing ones? How do you come up with ideas in general? There’s no fixed roadmap. It really depends on the client projects we’re handling. If there is something there that can be solved in a generic way, we’ll create a package. The past year we’ve been very active releasing packages regularly. Our output will diminish a bit in the coming months because we’ve already created so much. The most common problems in our projects are already solved with one of our packages. The only thing I’ve planned right now is the upgrade of the backup package. I want it to use Laravel 5.3’s native notification capabilities. There are a few package ideas floating around. I’m pretty sure some of them will get made in the near future.
7. What advice would you give to people who are planning to create Laravel packages? Any tips/tricks? Some time ago Jonathan Reinink create this great checklist for package creators: http://phppackagechecklist.com. Also a good resource is this talk by Hannes Van de Vreken at Laracon: To get started quickly take a look at our skeleton repo (obviously we use this at Spatie ourselves). Finally, when starting out creating packages start by creating a small one. * * * * * * I really appreciate Freek and his answers, if you want to follow him online, here are the resources:
- His blog: Murze.be
- His Twitter: @freekmurze
- His company: Spatie.be
- Their GitHub: Github.com/spatie
-front_grid.jpg)
-front_grid.jpg)
-front_grid.jpg)
No comments or questions yet...