badges / badges/shields

Packagist service improvements

Open
#7,783 0 comments 0 reactions 0 assignees View on GitHub
developer-experience service-badge
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.