https://composer.tiki.org supplies source code (external dependencies) that is bundled in Tiki, whereas packages-tiki-org is for code that is not bundled (An additional step must be done on each Tiki instance). This is known as Tiki Packages.
They both replace getting the code from https://packagist.org/ (which is the usual default for PHP development). Tiki has a Long Term Support cycle and this insures the code remains easily available to bundle in Tiki even if the original source is no longer available from Packagist.org (which is bound to happen when you have over 150 dependencies and a 5 year support period). Also, it gives the Tiki ecosystem more flexibility related to external changes like this.
- hosted on a server managed by the Tiki community
- offering packages for multiple Tiki branches/versions, including some old ones
- available both in http and https because some users require http (yes, https is better)
- powered by Satis
- built several times per day from https://gitlab.com/tikiwiki/tiki/-/blob/master/doc/devtools/satis.json.
- Note that https://composer.tiki.org will mirror ALL versions matching the "require" section of satis.json, which can use a very large amount of disk space to be used. Don't just reuse the semver used in package.json. Expecially for big, active packages. But a package matching the requirement of every supported tiki branch needs to be present. So best practice is to do something like.:
- Copy to clipboard"the_package": ">=4.0.4 || ^3.2.4 || ~1.3.2",
- 4.0.1 would be the minimum version of the current branch. 3.2.4 The minimum version supported by the previous branch, 1.3.2 the one before that. So
- Increasingly specific at is gets older.
- Start at the version first added to package.json (so >=4.0.4 not >=4 if you know no one ever used 4.0.3)
-
- Please keep this (and any similar) list alphabetically sorted.
- Note that https://composer.tiki.org will mirror ALL versions matching the "require" section of satis.json, which can use a very large amount of disk space to be used. Don't just reuse the semver used in package.json. Expecially for big, active packages. But a package matching the requirement of every supported tiki branch needs to be present. So best practice is to do something like.:
- Packages are mainly copied from:
- https://packagist.org/ (preferred)
- https://asset-packagist.org/ (second choice) but used less and less as JS and CSS dependencies are now managed via the The Tiki 27 plus Build System
- There is a way to get dependencies from elsewhere, like directly from a GitHub repo. But this is pretty much always done for legacy libs that are not available on Packagist.org, so please don't do this unless you know what you are doing.
To start using a new dependency, please make two merge requests:
- One to https://gitlab.com/tikiwiki/tiki/-/blob/master/doc/devtools/satis.json. Don't forget to respect the semver as all the versions of the packages matching the semver will be available on https://composer.tiki.org. Respecting the semver will also help us to reduce disk space consumption avoiding to mirror unimportant/unused versions of the package.
- And then to vendor_bundled/composer.json and vendor_bundled/composer.lock for the relevant branch
Why two merge requests? Doesn't this go against the concept of the Atomic Commit Convention? Yes, but satis.json needs to first be modified so package can appear on composer.tiki.org, and then, a few minutes later, it becomes available to be used.
About versions
- You need to understand https://getcomposer.org/doc/articles/versions.md
About replacing or removing a dependency
https://gitlab.com/tikiwiki/tiki/-/blob/master/doc/devtools/satis.json generates data for all Tiki versions. So if you remove a lib for Tiki 28, the lib will still be used for Tiki 27.x LTS. Tips: