[3.0] Manage third party libraries via composer

[MissAllSunday]

This is a simple POC for allowing SMF to handle their internal third party libraries via composer.

Some key features to take into consideration for this POC

• Composer is solely used by SMF, that is, no access to mod authors. Mod authors can still ship their own vendor folder if they provide their respective configuration for it
• Modifications to Simplemachines/build-tools will have to be made to further remove hardcoded instances of third party libs, happy to do those changes myself if required.
• SMF release process will need to change to accommodate composer commands.

[jdarwood007]

@Sesquipedalian, I want to tag this into alpha 5, do you agree?
We need to do this for easier maintenance and inclusion of other vendor libraries in the system, and isolate them from our code.

[Sesquipedalian]

@Sesquipedalian, I want to tag this into alpha 5, do you agree?

We need to do this for easier maintenance and inclusion of other vendor libraries in the system, and isolate them from our code.

I agree. I don't have capacity to review it myself right now (hard week this week), but I agree that it should be merged as soon as possible.

[dragomano]

I tested this on SMF 2.1, and there wasn't even a need to add $vendordir.

[MissAllSunday]

yeah we don't strictly need vendordir, it was added mainly for keeping things uniformed and if in the future the vendor dir gets moved somewhere else, same principle as sourcedir or themedir.

Will try to test this with mods that adds their own composer to see how they behave.

[Sesquipedalian]

Should also add a definition for this setting in Config::$settings_defs

[Sesquipedalian]

Not a complete review by any stretch, but I did notice something that needs to be changed

[Sesquipedalian]

Another problem: our .gitignore currently ignores the vendor directory, which means that ./vendor/autoload.php is not actually included in this PR. Since that file is clearly intended to handle the autoloading of SMF's own classes as well as third party libraries, it really needs to be included and tracked by our repository.

This also raises an additional question. Is it the intention of this PR for individual forums to use composer themselves in order to acquire the necessary third party libraries? If so, that would make composer a prerequisite for SMF, which I don't want to do. Our install and upgrade packages should contain all required third party libraries directly, with no additional requirement to have composer installed on the server. Of course, there is more than one way that we can do that, but it must be done one way or another.

[jdarwood007]

Not a issue. Its our build process that will have to change. We will have to have it run the composer installer, but in regular mode not dev mode. If your packing SMF on your local dev env, you will need to rm -rf vendor/* and then composer update to get it to the "stable" release we will make. We can add some composer actions for resetting the vendor folder to do just that if needed.

[Sesquipedalian]

Yeah, that should work. Still, we do need ./vendor/autoload.php to be committed to the repository, since it is going to be responsible for loading our own classes as well as the third party ones.

[MissAllSunday]

We don't really need to include the autoload file or any other files within the vendor dir, we only need to commit the composer.json and perhaps, the composer.lock file, which are the ones that determinate the current state of SMF's third party requirements.

This means that any developer looking to install SMF locally will have to have composer installed locally but then again, composer is, and has been from some time now, the de facto library manager for the entire PHP ecosystem so it shouldn't be an issue, for SMF's mod and theme developers who aren't used to composer, I can gladly post some guidelines on the wiki on how to install and use composer. This offers a lot of advantages since a mod or theme developer can easily reset their forums to a known state (the composer.lock file).

Regular SMF users (admin forums) won't have to interact with composer since at the moment they download SMF, the package will have all the necessary third party libraries already included in the .zip file they download, meaning the installation process will remain the same for them. This is possible because at the moment the SMF package gets generated (a process internal for SMF) all the libraries will be installed at the exact state the composer file requires them, ensuring we will always have the latest versions available when generating a new SMF package.

[jdarwood007]

Should note that a discussion in the PHP group around making more official: https://externals.io/message/128796

Concerns were ddressed