feat: add custom Composer repository support for extension version checking#588
Conversation
…ecking Allow shops to configure private Composer repositories (e.g. Packeton, Private Packagist, Satis) so that extension updates from custom package sources are detected during scraping. Supports Composer v1 and v2 formats with none, HTTP Basic, and Bearer token authentication. Credentials are encrypted at rest.
|
I would like to add a proper queue before and migrate to that before, we add those things as next |
|
Makes sense! Just to make sure, by "proper queue" do you mean moving the scrape jobs (both the hourly cron and the manual refresh)? I'll hold off on this PR until the queue is in place. Is there an issue tracking the queuing feature? |
|
I would like to parallelize using queue the scrapes. Still not sure which of those NPM packages we're gonna will use at the end: https://bullmq.io/ I expect to be done this week. |
| return timeDifference >= 24 * 60 * 60 * 1000; | ||
| } | ||
|
|
||
| interface ComposerPackageVersion { |
There was a problem hiding this comment.
can you move this composer foo into an own typescript file.
There was a problem hiding this comment.
Extracted all Composer repository logic to api/src/modules/shop/composer-repo.service.ts
| const data = (await resp.json()) as ComposerPackagesJson; | ||
|
|
||
| // Composer v2 lazy provider: metadata-url + available-packages | ||
| if (data["metadata-url"] && data["available-packages"]?.length) { |
There was a problem hiding this comment.
available-packages is optional in composer spec and does not require it.
There was a problem hiding this comment.
available-packages is now treated as optional. If it's present, we fetch only those packages. When absent, we fall through to process inline packages from packages.json.
2 participants
Closes #587
APP_SECRETencryptionChanges
composer_repositoriesJSONB column onshoptablelatestVersionTesting performed
make lintpasses with no new warningsSuggested tests