Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

Ligonsker's avatar

Is there a convenient way to see which packages were installed to the Laravel project?

Right now I can use composer show to list all packages and then compare that to a clean Laravel project. But that's tiring and prone to mistakes because it includes also the Laravel packages themselves

Is there a better way to get all the packages that were added to the Laravel project?

Ty!

0 likes
13 replies
OussamaMater's avatar

Well yes, if you create a fresh Laravel application, make a commit "Initial commit" (use Git to do so), at this point you'll have only the packages needed by Laravel, once you start working in the application and adding more packages, the composer.json will eventually change, and because you committed the first composer.json, you can compare what have been added to it and what have been in modified(in your Editor/IDE directly, because most of them now support GIt out of the box).

If you never used Git, these resources will get you started:

2 likes
md_imran's avatar

@oussamamater , you may check the composer.js file or normally try with terminal by composer show command.

composer show

It'll provide list of packages are you using. Thanks.

OussamaMater's avatar

@md_imran he said he wanted to compare* what has been added* that's why I mentioned Git, he's already using composer show :)

1 like
Ligonsker's avatar

@oussamamater @md_imran , I am using both composer and git and that's what I already did (compare them manually with git and composer show), but as you saw, it lists all the packages.

I was asking if it's possible to check on an existing Laravel project without comparing, what was installed as extra to the clean Laravel project

OussamaMater's avatar

@Ligonsker And can you re-read my comment? because that's what I literally mentioned, you don't have to compare with any project, you'll see what has been added, like a history.

1 like
Ligonsker's avatar

@OussamaMater Oh yes, you suggested to view the git history on the composer.json file :)

I can do that with composer.lock as well?

OussamaMater's avatar

@Ligonsker Yes you can, you can do that with any file not present in the .gitignore, and composer.json and composer.lock are not present.

If that helped you maybe close the thread by setting a "best answer" for future comers.

1 like
Ligonsker's avatar

@OussamaMater yes but I just asked in terms of getting what was installed, which file's history would show the installed packages better? the composer.json or composer.lock?

OussamaMater's avatar
Level 37

@Ligonsker Here are the differences:

  • composer.lock records the exact versions that are installed, this is useful when you're not the only one working on the project and you want to be in sync with the rest of the team.
  • composer.json is a description of your project, as it's defined by different packages, in other words it tells you what packages are being used in the current project, and what's their versions and some metadata.

Reading the composer.json is much easier if you want an overview of what's being installed, if you want more details like the requirements of a specific package than composer.lock is your friend.

And again, both are being tracked with Git, so you can review the history of both.

As a recap:

  • An overview of the project: composer.json
  • A detailed overview of the project: composer.lock

If that helped you maybe close the thread by setting a "best answer" for future comers.

2 likes
Snapey's avatar

@OussamaMater composer.json only shows the packages you installed, not all the dependencies of those packages. This is the real problem, understanding that a package requires three other packages and one of those requires three other packages, two of which are already installed because of some unrelated packages installed earlier

OussamaMater's avatar

@Snapey Yes true, composer.json gives a global overview of what's is installed, while composer.lock will give you these details you mentioned, and that's what I said I guess:

composer.json is a description of your project, as it's defined by different packages, in other words it tells you what packages are being used in the current project, and what's their versions and some metadata.

if you want more details like the requirements of a specific package than composer.lock is your friend.

Snapey's avatar

@OussamaMater No, you still miss the point.

composer show of a typical project lists approximately 150 packages.

composer.json, your 'overview' for the same project only includes 22 packages.

If you wanted to create a completely off-line installation, you would need all 150 packages loaded to your local repository. Not the 22 described in composer.json.

I agree with you that composer.json lists the top level - the reason all those additional 130 packages are pulled in - but thats not resolving @ligonsker question.

@ligonsker I would stick with composer show. You could write a line into the composer.json scripts section that runs composer.show and pipes it into a file. You can then include this file in your git version control so that you can track changes.

    "scripts": {
        "post-autoload-dump": [
            "Illuminate\Foundation\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi",
            "composer show > composer.current"
        ],

after adding or removing a package, or after composer dump-autoload a new file will be created called composer.current. Your version control will list the lines that have changed in that file.

1 like
OussamaMater's avatar

I got you, and that's a great way to do it actually, thanks for the new tips!

And based on his question, I don't really think he want to go that far? I mean he wants to see what he installed by himself, not what are the packages pulled when he installed a specific one, that's why I kept pointing the composer.json, I don't know if you understood what I mean, but it's like okay I installed X Y Z, these ones I want to keep track of, I don't really care if X installed A and B also (since I was not the one who pulled them manually by running composer install)

And again thanks for the post-autoload-dump trick! very useful

Please or to participate in this conversation.