Clarification about distributing a standalone application via Packagist

[osteel]

Hey there,

I just want to make sure I got a couple of things right – regarding the Distribute via Packagist section of the documentation about building standalone applications, do we agree that installing the app running composer global require my/app will install the app's Composer dependencies, but needlessly so?

In other words, Composer will automatically create a file in ~/.composer/vendor/bin pointing to the PHAR archive in the project's builds folder, which already contains all the code and dependencies. So while it also installs the project's dependencies, those are never actually used, right?

The other thing is that, while running some tests, I was able to install my app using composer global require my/app:old-version and then to run self-update to successfully install a newer version of my app.

Isn't that kind of weird/wrong? I.e. using one method to install the app (Composer) and another one to update it (PHAR self-update).

And if it's wrong, is there a way to programmatically know whether the app was installed using Composer and to conditionally hide/remove the self-update command in config/commands.php accordingly?

Thanks,

Yannick

[osteel]

I've answered the second question myself – while self-update seemingly works even when the app was installed via Composer, if you then try to upgrade the app again, this time running composer global update ..., the command doesn't fail but the app isn't actually updated. Not sure why though.

So I am now removing the self-update command when the app was installed via Composer by performing a check on the current directory (__DIR__), looking for the string .composer/vendor. Bit crude, but it works.

I still would like to know whether my first assumption is correct though (i.e. Composer installs the dependencies but they are not used).

[owenvoke]

Regarding your first query, if you leave the dependencies in the require section of your composer.json, they will be installed. This is why it is recommended to move them to the require-dev (other than the php version requirement). It's also recommended to exclude unnecessary files from your built archive (so that only the Phar is included).

You can see an example of this with the Oh Dear CLI:

• The .gitattributes excludes all content other than build/ohdear, and accompanying LICENSE.md, README.md, and composer.json
• The composer.json defines the PHP requirement for Composer, but the other dependencies are included in -dev so that they are not included when installing globally through Composer

As you have mentioned, correctly, if you specify the bin to be builds/foo, then it will bypass the included dependencies and files. It will only use the bundled dependencies from the Phar file.

---

Regarding your second query, I agree that is a bit of a weird scenario, and does seem odd to include that. However, I think in a way that makes sense as it's just a Phar file, so it has no knowledge of whether it's installed via Composer, Brew, Phive, or whatever. 🤷🏻 (Unless you do a check like you have).

I think, if you are wanting to disable the self-update command in that scenario, what you have mentioned is probably the best way. 🤷🏻

[osteel]

Now that's super interesting. It hadn't quite clicked why Laravel Zero's documentation was instructing to move the framework over as a development dependency – makes much more sense now!

Kinda feels like it should be made clearer in the doc?

[owenvoke]

Feel free to open a PR if there's anything you think would make it clearer. 👍🏻
https://github.com/laravel-zero/docs/edit/master/build-a-standalone-application.md

[osteel]

Thanks, just submitted a PR