Packagist service improvements
- Dominant language
- JavaScript
- Stars
- 27.2k
- Forks
- 5.6k
- Avg merge
- 1d 8h
- Merged PRs (30d)
- 46
Description
:clipboard: **Description**
Refs https://github.com/badges/shields/pull/7782#discussion_r835976765
At the moment we are validating the response before applying the decompression. This means we have to accept missing values and `__unset` in the validation. A better approach would be to do something like I suggested in https://github.com/badges/shields/pull/6508#issuecomment-855295658 - decompress the response first then validate it. This would have two advantages:
- It would allow us to clean up the schemas/validation - we can `.require()` the things that are required
- It would make it easier to "fall into the pit of success" when working on this code. At the moment if we add a new packagist badge it is really non-obvious that we need to call `expandPackageVersions()` on the response and if the latest release is stable you probably won't notice anything off. This should be handled transparently in the base class (both for `fetch()` and `fetchDev()`).
There may also be some test cases that need updating for this
Additionally at the moment there is a single `BasePackagistService` class for both the v2 API and the cached API but really these are two different APIs. If we're going to go down the route of overriding `_requestJson` we'll need to split this into two base classes as the cached API doesn't return compressed responses, but maybe this would be clearer what is going on to split into two base classes anyway.
Contributor guide
Research direction
Start by locating BasePackagistService, its fetch(), fetchDev(), _requestJson(), and expandPackageVersions() entry points, then inspect the related schemas and validation tests. Compare the v2 and cached API response paths, including existing test cases. Done means decompression and validation are handled transparently, schemas can require required values, and the two API variants have clear base classes with updated tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- api, backend
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100