Feature/yazio provider 1442

[thorethy1]

Description

What problem does this Solve?
This adds YAZIO as an experimental external food provider and makes it selectable in the shared mobile food-search flow.

How did you implement the solution?
Added YAZIO provider typing, settings support, server-side OAuth/search/barcode/detail mapping, v2 food routes and schemas, mobile API parsing/search support, and targeted tests. Mobile uses the shared React Native/Expo implementation, so the provider chip is available on both iOS and Android when the backend returns an active provider_type: "yazio" provider.

Linked Issue: Closes #1442

How to Test

1. From the repo root, install deps with corepack pnpm install if needed.
2. Validate frontend changes:

   cd SparkyFitnessFrontend
   corepack pnpm exec tsc -b
   corepack pnpm exec eslint . --max-warnings 0
   corepack pnpm exec prettier . --check

3. Validate backend changes:

   cd SparkyFitnessServer
   corepack pnpm run typecheck
   corepack pnpm run lint
   corepack pnpm run test -- tests/yazioService.test.ts

4. Validate mobile changes:

   cd SparkyFitnessMobile
   corepack pnpm run typecheck
   corepack pnpm run lint
   corepack pnpm run test:run -- --watchman=false --runInBand __tests__/hooks/useExternalFoodSearch.test.ts __tests__/hooks/useExternalProviders.test.ts __tests__/screens/FoodSearchScreen.test.tsx

5. Configure an active YAZIO external food provider and verify the Online food-search source chips show YAZIO alongside the other active providers.

PR Type

• Issue (bug fix)
• New Feature
• Refactor
• Documentation

Checklist

All PRs:

• [MANDATORY - ALL] Integrity & License: I certify this is my own work, free of malicious code, and I agree to the License terms.

New features only:

• [MANDATORY for new feature] Alignment: I have raised a GitHub issue and it was reviewed/approved by maintainers or it was approved on Discord.

Frontend changes (SparkyFitnessFrontend/):

• [MANDATORY for Frontend changes] Quality: I have run pnpm run validate and it passes.
• [MANDATORY for Frontend changes] Translations: I have only updated the English (en) translation file.

Backend changes (SparkyFitnessServer/):

• [MANDATORY for Backend changes] Code Quality: I have run typecheck, lint, and tests. New files use TypeScript, new endpoints have Zod schemas, and new endpoints include tests.
• [MANDATORY for Backend changes] Database Security: I have updated rls_policies.sql for any new user-specific tables. (N/A: this PR only extends the existing external-provider type/check constraints; no new user-specific tables.)

UI changes (components, screens, pages):

• [MANDATORY for UI changes] Screenshots: I have attached Before/After screenshots below.

Mobile changes (SparkyFitnessMobile/):

• [MANDATORY for Mobile changes] Tested on device or emulator: I have verified the changes work on iOS or Android. (Automated mobile screen/hook coverage was run locally; current web/PWA screenshots from the dev deployment are attached below.)

Screenshots

Click to expand

Before

The previous Online provider picker did not include YAZIO as a selectable provider.

After

YAZIO provider form

Default barcode provider includes YAZIO

Online search result from YAZIO

Edit food details from YAZIO result

YAZIO unit variants imported

Add-to-meal unit picker includes YAZIO units

Mobile: YAZIO provider settings (commit 49799ed)

Mobile: YAZIO search results (commit 49799ed)

Notes for Reviewers

• YAZIO requires server-level OAuth client credentials (YAZIO_CLIENT_ID and YAZIO_CLIENT_SECRET) plus provider username/password credentials.
• DM me for a YAZIO Test account you can use to actively test this implementation.
• The unofficial Yazio API uses OAuth2 credentials that I reverse-engineered from the official Yazio app. These credentials have never changed since the app's first lunch (6+ Years) and are hardcoded in the official app.
• The mobile app does not need platform-specific iOS/Android changes; it reads active providers from the existing provider API and supports YAZIO through the shared provider type list.
• corepack pnpm run validate in SparkyFitnessFrontend initially failed because tsc -b requires a build mode invocation; the equivalent checklist steps were run individually and passed: tsc -b, ESLint, and Prettier check.

[github-actions]

PR Validation Results

Change Detection

• 🖥️ Frontend changes detected
• ⚙️ Backend changes detected

✅ All checks passed. Thank you!

[gemini-code-assist]

Code Review

This pull request implements an experimental integration with the YAZIO food provider across the web frontend, mobile app, and backend server. It adds support for YAZIO product searches, barcode lookups, and credential management. Feedback on the backend implementation focuses on improving robustness and error handling in yazioService.ts. Specifically, the reviewer identified a potential division-by-zero bug when scaling nutrients, a concurrency issue with parallel token requests, and potential TypeError crashes if the API returns non-array data or if a null product is mapped.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[thorethy1]

Addressed Gemini review feedback in cd16e1a:

• Guarded variant nutrient scaling against zero/invalid serving weights.
• Deduplicated concurrent YAZIO OAuth token requests per account/base URL.
• Treat unexpected non-array search payloads as empty results.
• Made mapYazioProduct null-safe.

Validation after the fix:

• corepack pnpm run typecheck
• corepack pnpm run lint
• corepack pnpm exec vitest run tests/yazioService.test.ts

All passed locally.

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
33773161	Triggered	Generic Password	d7abc7b	SparkyFitnessFrontend/src/pages/Settings/ProviderSpecificFields.tsx	View secret
33773161	Triggered	Generic Password	2372148	SparkyFitnessFrontend/src/pages/Settings/ProviderSpecificFields.tsx	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}