Remove composer as a production requirement #144

New Issue

OVERLORD · 2026-02-04T17:16:40+03:00

OVERLORD commented

2026-02-04 17:16:40 +03:00

Originally created by @ssddanbrown on GitHub (Aug 8, 2016).

By removing composer as a production requirement it should make the install process easier and quicker.

Originally created by @ssddanbrown on GitHub (Aug 8, 2016). By removing composer as a production requirement it should make the install process easier and quicker.

OVERLORD added the 🛠️ Enhancement 🔧 Maintenance labels 2026-02-04 17:16:40 +03:00

OVERLORD commented

2026-02-04 17:16:44 +03:00

@lommes commented on GitHub (Feb 1, 2018):

I think the only way to do this, is to include all files from vendor/ (filesize will be between 20 and 25 MB). This is the only way to make it independant from hosting restrictions. There are lots of providers who do not offer ssh in basic hosting plans which are totally fine for BookStack.

Updating dependecies is not really difficult, since this is nothing a user does on a regular basis. The vendor folder, which is generated by composer install from the update steps, will be including the same versions of packages a user gets until the next release of bookstack.

In my opinion the main points to consider are:

How to enable the "updater" since we can not rely on BookStack-Logins because the System might be broken until the updates are performed. This might be achieved by simply placing a file with a defined name in a defined folder which will be deleted after the update is performed.
How to determine which steps need to be taken. This is easy for things like migrations and clearing cache/view because we can use the artisan commands from code. Files which are not included in the download (.env) might change. We can simply tell the user to compare relevant files (.env with .env.example) and ask them to manually merge changes.

The easiest way would be implementing a route which looks for a specific file, runs artisan migrate, artisan cache:clear and artisan view:clear, displays generic information which files might have changed that the user has to merge manually and finally delete the enabling file.

@lommes commented on GitHub (Feb 1, 2018): I think the only way to do this, is to include all files from vendor/ (filesize will be between 20 and 25 MB). This is the only way to make it independant from hosting restrictions. There are lots of providers who do not offer ssh in basic hosting plans which are totally fine for BookStack. Updating dependecies is not really difficult, since this is nothing a user does on a regular basis. The vendor folder, which is generated by composer install from the update steps, will be including the same versions of packages a user gets until the next release of bookstack. In my opinion the main points to consider are: - How to enable the "updater" since we can not rely on BookStack-Logins because the System might be broken until the updates are performed. This might be achieved by simply placing a file with a defined name in a defined folder which will be deleted after the update is performed. - How to determine which steps need to be taken. This is easy for things like migrations and clearing cache/view because we can use the artisan commands from code. Files which are not included in the download (.env) might change. We can simply tell the user to compare relevant files (.env with .env.example) and ask them to manually merge changes. The easiest way would be implementing a route which looks for a specific file, runs artisan migrate, artisan cache:clear and artisan view:clear, displays generic information which files might have changed that the user has to merge manually and finally delete the enabling file.

OVERLORD commented

2026-02-04 17:16:45 +03:00

@ssddanbrown commented on GitHub (Mar 11, 2025):

Started building out a system:

During release publish:
- A fresh --no-dev composer installed vendor directory is zipped up.
- A sha256 checksum is taken of the ZIP, and written to a dev/checksums/vendor file, which is committed as part of the release.
- The ZIP is uploaded to https://files.bookstackapp.com/vendor/ and named to match the BookStack version.
- A script automates these steps: script here.
On Update:
- The ZIP of matching version can be downloaded.
- The local instance checksum can be used to validate the ZIP.
- The ZIP can then be extracted into the BookStack instance.
- I've added a system CLI command which can be used to automate these steps, so it's just a case of running ./bookstack-system-cli download-vendor instead of composer install --no-dev.

Edit: Relevant blogpost: https://www.bookstackapp.com/blog/php-dependency-improvements/

@ssddanbrown commented on GitHub (Mar 11, 2025): Started building out a system: - During release publish: - A fresh `--no-dev` composer installed vendor directory is zipped up. - A sha256 checksum is taken of the ZIP, and written to a `dev/checksums/vendor` file, which is committed as part of the release. - The ZIP is uploaded to https://files.bookstackapp.com/vendor/ and named to match the BookStack version. - A script automates these steps: [script here](https://codeberg.org/bookstack/devops/src/branch/main/meta-scripts/bookstack-store-vendor). - On Update: - The ZIP of matching version can be downloaded. - The local instance checksum can be used to validate the ZIP. - The ZIP can then be extracted into the BookStack instance. - I've [added a system CLI command](https://codeberg.org/bookstack/system-cli/commit/6e6b8f0fdbc153b672dbbf6621bc56b310c4e3ea) which can be used to automate these steps, so it's just a case of running `./bookstack-system-cli download-vendor` instead of `composer install --no-dev`. Edit: Relevant blogpost: https://www.bookstackapp.com/blog/php-dependency-improvements/

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#144