Learning Composer for PHP | Micah Wood | Skillshare

Learning Composer for PHP

Micah Wood, WordPress Developer

Learning Composer for PHP

Micah Wood, WordPress Developer

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
11 Lessons (35m)
    • 1. Introduction

      2:49
    • 2. Lesson 1 - Installing Composer

      2:39
    • 3. Lesson 2 - Initializing Composer

      4:09
    • 4. Lesson 3 - Declaring Dependencies

      3:16
    • 5. Lesson 4 - Discovering Packages

      2:26
    • 6. Lesson 5 - Specifying Versions

      7:17
    • 7. Lesson 6 - Working with a Team

      2:26
    • 8. Lesson 7 - Private Packages

      3:01
    • 9. Lesson 8 - Releasing Packages

      4:36
    • 10. Lesson 9 - Project Bootstrapping

      1:00
    • 11. Conclusion

      0:57
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

62

Students

--

Projects

About This Class

When is the last time you copied and pasted the code from one project to another? Are you frustrated that you are constantly working hard and other developers still seem to be more productive than you?

Well, if you haven't learned about Composer or how to leverage it, you should definitely take this course.

Composer is a command line dependency management tool designed for PHP. It allows you to declare the libraries your project depends on and it will manage them for you. At least that is the definition that the documentation gives you. 

In reality, Composer is a tracking system that allows you to not only release and reuse your own code, but also leverage code that was written by other developers to make you a more efficient developer and more effective problem solver.

You will learn how to:

  • Install Composer
  • Setup Composer in your projects
  • Find and install your code dependencies
  • Properly use versioning to reduce the chance of code conflicts
  • Use Composer when working with a team
  • Utilize private code bases as dependencies
  • Release your code for public consumption
  • Quickly bootstrap new projects

I recommend that you have some familiarity with the command line, but even if you don't we won't be covering anything difficult in that regard. I also recommend that you have some experience working with version control. Really, this isn't absolutely necessary either but is a best practice and hopefully something you already do. Of course, this is a PHP dependency manager so if you aren't working with PHP this course won't help you much.

Composer is a tool that can really take your career to the next level, so let's get started learning today!

Meet Your Teacher

Teacher Profile Image

Micah Wood

WordPress Developer

Teacher

Micah Wood is a WordPress Developer at Bluehost. A professional WordPress developer for over a decade, Micah has worked on sites for Fortune 100 companies, has released over a dozen WordPress plugins, is a frequent speaker at WordCamps, co-organizes the WordPress Gwinnett meetup, is a co-host on the WP Square One podcast and shares his knowledge by blogging on WordPress and development topics.

See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Your creative journey starts here.

  • Unlimited access to every class
  • Supportive online creative community
  • Learn offline with Skillshare’s app

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

phone

Transcripts

1. Introduction: Hi, My name's Michael Wood and I want to welcome you to my course Learning Composer for PHP. I've been working with PHP for a good long while actually have been a developer for 10 years now, five years working in enterprise development. So I want to introduce you to the topic of composer. Basically, composer is a tool. It is a SEAL I tool or command line tool that you'll use to manage dependencies and PHP. So if you haven't used composer before, this is one of those tools. It's easy to overlook and say, Oh, well, I don't need it But the reality is that this is one of those tools that will really make you a better developer for a number of reasons. There's this principle called the reuse release principle. And basically what this says is that your ability to reuse code is dependent on your ability to release the code via some sort of tracking system. And by tracking system, this basically means that you're able to release code in a version way, so that when you want to reuse the code, you can actually just call it in at a particular version, using a dependency manager like composer, and that is how you can easily reuse your code. A common problem is people will decide. Oh, this is good code. I'm going to use it on this other project will copy it to a few different projects. And then over time, some of those projects get bug fixes. Each one gets a little bit of a different fix. So when you want to go reused the code later, you're not really sure which code you should be using because they're all different. So if you'd use some sort of version ing or tracking system for your code like composer, you would be able to know that Hey, this is the version of the code that I should be using. And you will be able to utilize your code more efficiently, not just your code, but you're actually able to utilize other people's code better as well. So I encourage you as you go through the course. Uh, this is not one of those things where you'll end up with a final project per se. This is more of a workflow process. Really. What you'll be posting in your project updates is how you got the tool to work for you. So I encourage you to implement in your daily workflow and then report back and say, Hey, I found composer helpful in this way or I'm using it this way. Those are the kinds of things that we want toe find out about. I'd encourage you to fall in my profile so that as I released new courses, you'll be able to get the latest If you ever get stuck just post in the discussion section , whatever questions you have or what you got stuck on, provide some details and I'll be happy to help. Or I'm sure there will be some other students that might be able to help us. Well, so I'm excited. I hope you're excited, and I look forward to seeing you in the course. 2. Lesson 1 - Installing Composer: In this first lesson, we will be learning how to install composer. Keep in mind that composers of Seelye or command line tool on Windows you'll need to locate and open up your command prompt program on Mac. You'll need to locate and open up your terminal program. I'm on a Mac, and as you can see, I have my terminal program open. And if you want to follow along, we're going to type in composer Dash V to validate. The composer is not installed yet. The next step is to go to get composer dot work where I'll walk you through How to install Composer for both windows. Hand for Mac For a Windows installation, click on getting started and then find the Windows installation link. There is a composer set up Execute herbal file that you can install and run to install Composer on your machine. If you have a Mac, you'll want to click on the download link at the top of the page, and there will be a series of commands that you will be able to copy and paste to do the installation. The 1st 1 is going to copy down the installer called composer set up that PHP. The next line is going to validate that the installer is valid and hasn't been corrupted. The third is going to actually run the installer and download composer itself. And as you can see, we have a composer far file. The final line is actually going to get rid of the composer, set up PHP file installer so that we're left with just the composer dot phar file. We can run PHP composer dot phar and as we can see composers working but we would rather just be able to run composer itself. So we're gonna do a global installation. So if we go to getting started and find the global installation link for Windows are for Mac will highlight the command and paste it in. And that will basically move our composer dot phar file into a location that is in the global scope. We can now run composer and as you can see, it works. And finally, we're gonna run composer diagnosis to check our system and make sure there are no issues with the installation 3. Lesson 2 - Initializing Composer: in this lesson will be learning how to initialize composer in her own projects and learning about the composer, innit? Command, which will create a new composer dot Jason file. Their point of the composer dot Jason file is it allows us a location where we can define our dependencies for the project that we're working on. Or it can also define metadata, which will allow us to use our project within other projects in the future. So to get started, we're going to go into our foul system and creating new folder, and I'm going to call it Demo Project. And from there I'm going to switch over to the terminal and do CD demo project, which is gonna change us into the same directory as we just created. Finally, we're going to run the composer, innit? Command, which is going to open up a series of questions. The first thing it wants to know is the package name, which is usually broken down by a vendor name space, followed by a slash and then a package name. In this case, it is automatically selecting the get hub handle from my git config file on my machine. And then using the folder name as the default name for the project. The vendor name is usually unique to a particular organization or person, so I suggest that you choose a vendor name and stick with it. And then the package name will be unique within the vendor name space. The description is essentially description of your project. The author is going to default to your get hub name and email address in your git CONFIG file, but you can enter end using the same format as displayed here your name and email address. If you'd like it to be different, minimum stability defaults to stable, which means that any time you try to install a package that is below that level, such as a development package, something in Alfa or beta or a release candidate that it will not install, you can reduce this to a lower level if you want to allow those types of packages. Although I typically consider setting this at a global level not ideal, I would prefer to set flags at the individual package level, which we'll discuss later. The package type defaults to library, although you can set it to a number of different things library and project or the most common, and in this case, we're going to set it to project, since we are creating a project that consumes dependencies as opposed to creating a library that will be consumed by other projects, the license is essentially the license under which your project or library will be released . It is possible to set it to proprietary if it's something that will not really be released , or you can go to SPD ex dot org's slash licenses and find the license of your choice, and you can enter the identify air in here. I do a lot of WordPress projects, and that is falls under the GPL license. So I typically use GPL 2.0, or later as the identify air next is gonna ask if we want to define our dependencies Interactive Leawere just going to say no because we're gonna do that in a later lesson. And finally, it will generate a composer dot Jason file for us, and we just validate that What we see is what we want. And once we open up the file, we can see that indeed, the composer J some file contains what we expect. We can also run composer validate to ensure that the file is valid if we ever do make any kind of manual edits to the composer Jason File. 4. Lesson 3 - Declaring Dependencies: in this lesson, we'll be learning how to declare dependencies within Composer, which will be doing via the composer, require command. And the reason we'd want to declare dependencies is so that we can utilize someone else's code in our project, or so that we can reuse our own code that we've released as a composer package. So the composer require package command will essentially add whatever package we define to our composer dot Jason file and go ahead and install it forests automatically. We're gonna start by running composer require for a particular package, my cow slash flight, and this is going to download that particular package to system. And as you can see, there's some file system changes that just took place. First, we're gonna take a look at the composer Jace on file and see that there's a new require line, which includes our package. At that particular version, there's a vendor directory where all of our packages actually live. They're in the vendor slash package name structure, and then we have a composer lock file, which was generated, and we'll discuss and go into more depth as to what this is. A bit later, one of The most important files to be aware of is the auto load that PHP file. This lives in the vendor directory and is what you will require in your project so that all the dependencies will auto load if you're not familiar with auto loading. Essentially, what this means is that files in your dependencies that you add will be loaded on demand. This also means that by design, composer packages should not do anything by default when the files were loaded. Normally, composer packages will require you to run some sort of initialization code in order to kick things off. If you'd like to load a specific package at a specific version, you can always do composer require the name of the package and then type in the specific version that you would like. And, as you can see, we're currently downgrading from 135 to Version 12 of the same package we installed just a bit ago. It's also possible to require a package, but only for development purposes. So what we're gonna do is require PHP unit, which is only used for development by doing a dash dash Dev at the end. This declares that it is a development only dependency. And as you can see, it is loading in PHP unit into our project, which comes along with a bunch of other dependencies. Composer is recursive in nature, so if a dependency has other dependencies, it will load all of the men. As you can see, we have PHP unit and quite a few other dependencies as a result. 5. Lesson 4 - Discovering Packages: in this lesson will be learning about discovering packages. You are probably wondering in the last lesson how we knew how to find a particular package that we wanted to require and in this lesson will be learning about how to find this packages and a few little tips on finding reputable packages. So how is Composer aware of available packages? There's a website called packages dot org's, which serves as a repository of packages, a registry per se that composer uses as a reference when looking for particular packages. So if you wanted to release the package, you could register it with package IST, and then composer would be aware of it any time. It needed to require a package based off of the vendor and package name. So there's a couple of ways you can go about finding these packages. One is you can just go to packages dot org's and you could do a search and find packages, and the other is You can actually use this Eli tool itself. So if I do a search for my own vendor name space, I can pull up my packages. You can see there ordered by stars and the number of downloads, and if you click into the package, you can see that the number of installs is listed. The best indicators of a good package are going to be the number of downloads, the number of stars, the date that a package has most recently been updated. And, of course, you'll want to click through and actually look at the code itself. If you prefer to perform searches from the Seelye tool itself, you can use the composer search, command and type in a keyword, and it will pull up all of the matching packages. So here we're doing a composer search for my vendor named WP Scholar and its listing them all out. We're going to use composer browse WP scholar slash WP dash skeleton and this is going to pop open the window. It takes you directly to the get hub repo so you can explore the code and look at the package for yourself. 6. Lesson 5 - Specifying Versions: in this lesson, we're going to be learning about why version ING is important in regards to selecting the versions that are allowed of a particular package within composer version. ING is important because it provides a framework for releasing and consuming code and making sure that all the packages work together. And if we don't have this foundational framework, things can get pretty hairy pretty quick. So this is the composer Jason File that we were looking at earlier, and you'll notice that the first package in the require section is add version 1.2, which is pretty clear. The PHP unit package, which is in the required Dev section, is actually at Carrot 7.3, which is obviously not an exact version. And that is because there are some different meanings to the symbols and the ways that you can indicate versions in composer and those are very important, and I want to discuss what those are and exactly how those can impact your project. In certain cases, it is common that you are too restrictive in your version declarations, So if you would always use exact versions of your packages, you would get into a situation called version lock. This is where you will be unable to update without releasing new versions of dependencies. In other words, the dependencies air so strict that you can't update one package without updating all the other packages, which obviously is not an ideal scenario. Additionally, you can run into an issue called version promiscuity, which is where you're too loose with your versions, and you assume compatibility with more future versions than is reasonable As a result, what ends up happening is when you go to run an update, it will actually update more things than you intend to newer versions. Then you intend, and you will actually have issues where conflicting packages will actually cause your code to break. By standardizing the rules around version ing, we can avoid a lot of these situations where we enter into version, lock or version. Promiscuity. Semantic version ing 2.0 is documented on cem ver dot org's If you'd like to go and check out all the details, but I'll give you a quick run down of the basics version. Numbers typically have three numbers. The first is what's called a major version, and this is incriminated any time you make breaking changes to your code. Regardless of whether you've implemented new features or done some bug fixes anything that has breaking changes that breaks backwards compatibility, you'll increment the major version number. The second number or minor version number is incriminated anytime you add backwards compatible features to your code. So this is when you've implemented a new feature but haven't broken anything for your previous users. The final number or the patch version number is going to be implemented any time that you make backwards compatible fixes to existing features. So you're not implementing new features. Your just simply fixing bugs. But you haven't done anything to break backwards compatibility. As you can see, the semantic version ING framework allows us to take a look at the version number of the package we're using now and the version number of the package that we will consider upgrading to. And as a result, if the first number is changed, we can assume that they're breaking changes and that we may want to be more careful when we upgrade. However, if the second numbers been updated, we know that we're getting new features, but nothing is going to break considerably, or at least expected to break. And then, finally, the last number the bug fixes, if we only wanted to get bug fixes we could define, are allowed versions in such a way that we would only get the bug fixes for the packages we have in use. The first and most obvious way that we can define our version is with an exact version, and what this means is that we will not get anything except for the prescribed version when we were on an update. So even if there's a new update, which contains bug fixes or otherwise, none of those will be received unless we change how the version structure is defined. Alternatively, we can define a range of virgins. In this case, we're defining greater than or equal to one point. Oh, but less than 2.0, so anything that is a bug fix or a new feature will be received in this scenario, but not a breaking change. We can also use wild cards in our versions, and typically this is used in the bug fix placeholder in order to make sure that we always get bug fixes for a specific package, understanding. The next significant release version can be tricky. Essentially, the tilt e operator will lead the way, and then you'll have a version number. Whatever the last number is that's defined will be allowed to go up, but not the number to the left of it. So in this case of 1.2 with utility in front means that you will get every version for new features and buck fixes up until but not including version two. Point up. However, if you are to add a number after the two and make it 1.2 dot one, for example, then it would only allow the bug fix value to go up. And we'll give you all the bug fixes, but not the next new feature. Ultimately, there's a lot more to version ing than just thes three numbers. You'll have development releases Alfa and Beta releases, release candidates. And then, of course, you're stable releases, which typically fall within the bounds of what we've just been speaking of. So it is possible to define version stability flags in composer to get whatever the latest stable version is. For example, regardless of whether there is a breaking change or not, or you could do the same with all the other types of releases as well. So if you wanted to, for example, use thes stable stability flag. You could easily replace the version number within at stable, and that would give you the latest version regardless for that particular package, as long as it's a stable version. 7. Lesson 6 - Working with a Team: in this lesson. I want to talk about working with a team when using composer. So there's a couple things you have to keep in mind when you're working with a team. One. You've got to make sure that the right things get into your repository. You're get Hub repository or whatever tool your using for that. And you need to understand the workflow so that the person who's updating dependencies does the right thing. And the people who are not supposed to update dependencies do the right thing. So the vendor directory is where composer installs all of your packages. The Vendor directory is generated after running composer Install. So ultimately, you do not want to commit the vendor directory to your get repo, because that will be automatically generated anytime. Composer installers run Composer Install is the command that your team will run every time that they want to pull in the dependencies. The composer dot Jason file is the file that is generated when you first run composer in it and is then updated every time you run composer require with your dependencies or packages that you want to include the first time that you run. Composer install. It will actually read the composer dot Jason file and figure out what dependencies are allowed at what versions and then we'll decide exactly what versions to install. If you run Composer installed at a later time, it will actually read a file called a Composer dot lock file. This lock file defines the exact versions of the actual installed dependencies, and this is how everyone on our team when we run composer install, get the exact same versions, despite the fact that there may have been updates to specific packages between the time that we ran the composer installed command. On the other hand, the Composer Update Command will check for and install package updates based off of the composer dot Jason file. So every time you run composer update, it ignores the lock file because it doesn't care about the actual installed dependencies. It only cares about what's allowed and what's available at that point in time. 8. Lesson 7 - Private Packages: in this lesson will be learning how to take a private package that is either a private get hub repo a bit bucket repo that is not public or even if it is a public RICO, something that hasn't been published on two packages dot ord. We can use within our projects without necessarily having to make the repository public or having to publish the package on two packages dot ord. The first thing that you need to do to make a private repo usable within composer is to make sure that you have a composer Jason file in your project. So this means you'll need to run the composer and knit command to generate the composer dot j Some file and you'll need to commit that to your repository. So here I have an existing repository called WP scholar slash WP post expiration, and it has an existing composer dot Jason file in it. As you can see from the composer dot Jason, file the name of the package. His WP scholar slash WP dash post dash expiration. As we already know, packages dot org's is the central repository where composer looks to find any registered repositories or packages In the case of a private repository, you will need to essentially register your repository with composer directly in the project . So there's a bit of a complicated command. Composer config repositories dot name of package get and then they get hub. You're out. Assuming you're using get up in order to run, this command will want to make sure that we grab the get euro going to open up the composer Jason file just for demonstration purposes. And we're gonna paste in the full command here, which is gonna be composer config repositories dot package name, which really could be anything but we're using WP scholar slash WP post deaths expiration get and then they get your out. Now our composer Jason file has been updated to include our repository as a custom package . Now we are able to run composer require and then our package name, and it will include the package from the get repository, just like if it were registered on packages dot orig 9. Lesson 8 - Releasing Packages: in this lesson will be walking through the process of publicly releasing a package to packages dot org's so that it could be used by anyone who uses composer. I have a pre existing repository here called WP scholar slash. Hello, world. And I want to release this package on packages so that it could be used publicly with composer. So we're gonna walk through that process first. I need to clone down the repo so I could make some changes. So I'm gonna snag the get euro, and now I'm gonna clone down the repository. As you can see, we have the repository clone down right here, and I'm gonna change into that directory. And now we're gonna run Composer in net in. Answer the questions. And as you can see, we now have a composer dot Jason file. We don't really need a require line in this file because we don't have any dependencies within this particular package. But it's entirely possible that you might. The important thing is the metadata located here at the top of the file. This is what will register your package with package ist under most importantly this name. So make sure you have this name correct and in the correct format. So now that we've added the composer dot Jason file, we need to push that composer dot Jason file up to our repository. So I'm going to do a get ad composer dot Jason and then they get commit with a message. As you can see, that's been committed. But we now need to push that up to a repository. Great. So let's switch back. As you can see, we have a composer dot Jason file located here, and it matches what we just pushed up. We're almost ready to release this package on package ist, except we need to do one more thing. We need to make sure we have a stable release so that when people try to require WP scholar Slash hello world, they will be able to pull the 1.0 version. At the moment, we have two releases, but these are 0.2 and 0.1 which are not considered stable releases, according to semantic version. So we're going to draft a new release version one Dato and go ahead and publish it. Great. We should be ready to release this on packages We're gonna copy the euro from the get hub home screen and I'm already logged into packages. As you can see, I'm gonna click Thesis, admit button at the top of the screen and paste in the get hub. Your L and hit check packages doesn't want you to release packages that are already in existence on packages. There's obviously a lot of hello world packages, so I'm gonna hit Submit Great. So now packages has crawled our git repository and pulled in all the pertinent information . As you can see, we have a 1.0 version that's been released to get Hub Your Alice here. So now if anyone were to run composer require WP Scholar Slash Hello world, This package would load in 10. Lesson 9 - Project Bootstrapping: in this lesson, we're gonna learn about project bootstrapping so you can get up and running on a new project with minimal effort. So the composer create Project Command can be used with any publicly released composer package. And basically, what will happen when you run? Composer Creek Project is Composer will download the project and run Composer Install. So let's say you wanted to get up and running quickly with a Lauraville project. You could run composer, Create project lauraville slash lauraville and what would happen is it would download Lauraville and then it would run composer install within the level project to pull in all of its dependencies and ultimately, what you end up with is a complete level project ready to go. 11. Conclusion: So you've reached the end of my course and I hope you enjoyed it. I hope you learned a lot. So just to kind of recap what we've covered, we learned about what composer is, how to install it, how to initialize it in our projects, how to declare dependencies, how to discover, where to find packages that we can include in our projects and how to work with the team and run the right commands at the right time and make sure that we include the right things and are repositories. And finally, we learned how to bootstrap projects quickly how to leverage composer to get up and running in no time at all. So I encourage you to share what you've learned and how you views composer in the project section and follow my profile so that as I post new courses, you'll be able to find out about them and join in. And again, if you did get stuck or have questions, there's a lot of more advanced techniques and things we did not cover in this class. So feel free to ask in the discussion section, and I'll be happy to answer what I can