در حال بارگذاری ...

Forking the Repository0:00

With our project selected, I think it's time we get this installed locally so we can begin to play around with our Idea. Of course, we could go ahead and hit the code button here, copy the URL and git clone directly, but then we won't actually be able to make a pull request to prompt because we don't have any form of ownership over this project. So instead, we need to fork this project into our own personal GitHub profile. From there, we'll be able to git clone and that will allow us to push changes up and then make a PR back to Laravel prompts later down the line. So let's go ahead and hit this fork button. You can stick with the defaults, but if you want to rename this to something else, feel free. If you want to change the description, feel free. And this little checkbox here is quite important. If you only want to make changes to the current version, you should be ok with

If you want to change the description, feel free. And this little checkbox here is quite important. If you only want to make changes to the current version, you should be ok with copying the main branch only. But if you're trying to make changes to a future version or a past revision of the package, you might want to copy all branches over. Different projects handle branching differently, so keep that in mind. For example, the Laravel framework dictates that you should be sending most features to the 10.x branch unless they contain breaking changes, in which case they should go to master. So for something like Laravel framework, it would make much more sense to include all branches when forking. For our use case, I'm going to copy the main branch only, hit create fork, and then wait just a few seconds while GitHub does its thing. Now you can see we have our very own version.

Cloning Locally1:32

For our use case, I'm going to copy the main branch only, hit create fork, and then wait just a few seconds while GitHub does its thing. Now you can see we have our very own version of Laravel prompts that we own and GitHub will inform us where we are in comparison to the original Laravel prompts. As soon as we've only just cloned it, we are up to date with Laravel prompts. But something that I often forget is that you need to sync your fork regularly. So come back to this page, check if this is saying we're out of date, and if so, you can sync the fork right here. Ok, so from our forked version of Laravel prompts, let's click the code button. We'll copy the HTTPS URL, and then from our terminal, we can type git clone and I'll drop that URL in. And I've opted to add this to a packages/laravel directory. I do that to try and group together all the different

Opening in IDE2:18

we can type git clone and I'll drop that URL in. And I've opted to add this to a packages/Laravel directory. I do that to try and group together all the different packages that I fork and clone so that I can find them easily on my system. But use whatever works for you. Once git clone has been installed, why don't we cd into our new prompts package and then I'm going to open this up inside our IDE, phpStorm in my case. And here we go. We have a local version of Laravel prompts from that fork that we just created. The first thing we need to do is get it working. Make sure that it's up and running. Perhaps the simplest way to do this is to execute the tests. And if the tests all pass, it's a good indicator that things are up and running locally on your machine. So why don't we see if there's a script to do that. Hmm. Let's scroll down inside composer.json. All right. No scripts

Installing Dependencies & Running Tests3:06

indicator that things are up and running locally on your machine. So why don't we see if there's a script to do that. Hmm. Let's scroll down inside composer.json. All right. No scripts to do that. Let's see what test framework it's using. It's using pest. So technically speaking, we should be able to run vendor/bin/pest and see the test run. But you can see currently it says there's no such file or directory, which is what you'd expect. We've not actually installed any of the composer dependencies. So as a first step, why don't we say composer install. With our composer dependencies installed, we can once again run vendor/bin/pest. And look at that. It's executing all of the tests, all 120 tests pass in 2.26 seconds, which I think means we're up and running. Why don't we have one quick check through the routes here of the project? README. Well, there's nothing to

Verifying Setup & Next Step3:47

pass in 2.26 seconds, which I think means we're up and running. Why don't we have one quick check through the route here of the project? README. Well, there's nothing to do with installation steps. So I'm pretty sure that it's as simple as actually just doing a composer install. We haven't got package.json, so there's no NPM dependencies to install. Yeah, this looks great. So there we go. Project installed. We are ready to start writing code. But before we do, there is one very important step that you must not miss. We'll talk about that in the next episode.

دوست دارید گاهی خبرهای Laracasts را ایمیل کنیم؟