feat!: Frontend infrastructure

[PaulKMueller (PaulKMueller)]

Changes

Introduces the shared infrastructure for static report frontends:

• Adds the Vite/React frontend package and packages its build output with quant-ranger.
• Adds quant-ranger frontend export and GitHub Pages deployment documentation.
• Standardizes updater artifacts passed to aggregators.
• Updates CI, packaging, dependencies, and tests.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (8b47c27) to head (67d4c14).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #24   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           49        50    +1     
  Lines         3077      3122   +45     
=========================================
+ Hits          3077      3122   +45     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Yannik Tausch (ytausch)]

As mentioned via DM (copying here for visibility), could you ask your agent to bring test coverage back to 100%? That’s the standard we follow in this repo, since adding and maintaining these tests is relatively inexpensive compared with manually assessing whether coverage is sufficient.

[Janina Wibker (JaninaWibkerQC)]

This is a huge red flag that you need to re-allow these folder like this.
This is a flaw of the default .gitignore that we use which is insanely messy and needs to be cleaned up at some point.

In this case here I recommend removing everything that isn't strictly necessary and maybe contributing this back in the future

I used the following one somewhere else, maybe this is a good starting point:

# Explicitly unignore hidden files for ripgrep. Individual folders can still be ignored in the blocks below.
!.*

# macOS
.DS_Store
*.icloud

# IDEs
.idea/
.vscode/

# Python
__pycache__/
.pytest_cache/
.mypy_cache/
*.py[cod]
*$py.class
.ipynb_checkpoints
.ruff_cache/
*.egg-info/
*.egg
.pixi

# coverage
.coverage
.coverage.*
coverage.xml
/coverage

# build outputs of all kinds
build/
out/
output/
dist/
.cache/
/site
docs/_build/

# dotenv files and related
*.pem
*.env
*.env.*

# frontend
node_modules
.pnpm-debug.log*
.pnpm-store
*.tsbuildinfo

playwright-report/
test-results/

[Janina Wibker (JaninaWibkerQC)]

Bit of a personal opinion, but nesting task different task runners is an anti-pattern.

Just use pnpm directly without having to replicate every. single. script. as a pixi task

pixi run pnpm dev works. Alternatively just use pixi shell

[PaulKMueller (PaulKMueller)]

Thanks for the idea!
I would push back on this a little.
We get a simpler .lefthook.yaml as well as simpler CI and one developer entry point.
Most people will never need to run any pnpm commands in this repo.

In the current state, people can just look into the pixi.toml and see all relevant entry points for development.

[Janina Wibker (JaninaWibkerQC)]

Just use:

• format:check: biome check .,
• format:fix: biome format --write ., and
• lint: eslint .

The amount of commands is overkill

[Janina Wibker (JaninaWibkerQC)]

nit: why is this suddenly needed? if it is indeed legacy why wasn't this line needed previously?

[Janina Wibker (JaninaWibkerQC)]

use eslint-plugin-better-tailwindcss as well:

import pluginTailwind from 'eslint-plugin-better-tailwindcss'

// ...

{
    files: ['**/*.{js,jsx,ts,tsx,mdx}'],
    languageOptions: {
      parserOptions: {
        ecmaFeatures: {
          jsx: true
        }
      }
    },
    rules: {
      ...pluginTailwind.configs['recommended-warn'].rules,
      'better-tailwindcss/enforce-consistent-class-order': 'error',
      'better-tailwindcss/enforce-consistent-line-wrapping': 'off',
      'better-tailwindcss/enforce-consistent-variable-syntax': 'warn',
      'better-tailwindcss/no-conflicting-classes': 'error',
      'better-tailwindcss/no-duplicate-classes': 'warn',
      'better-tailwindcss/no-restricted-classes': 'error',
      'better-tailwindcss/no-unnecessary-whitespace': 'warn',
      'better-tailwindcss/no-unknown-classes': 'error'
    },
    plugins: {
      'better-tailwindcss': pluginTailwind
    },
    settings: {
      'better-tailwindcss': { entryPoint: '<path-to-tailwind-config>.css', rootFontSize: 16 }
    }
  }

[Janina Wibker (JaninaWibkerQC)]

Suggested change

	import tseslint from 'typescript-eslint'
	import { configs as javascriptConfigs } from '@eslint/js'
	import { configs as typescriptConfigs } from 'typescript-eslint'

and then use:

javascriptConfigs.recommended,
typescriptConfigs.recommended,
typescriptConfigs.recommendedTypeChecked,
typescriptConfigs.stylisticTypeChecked,

instead of only [js.configs.recommended, ...tseslint.configs.recommendedTypeChecked].

The change to the variable names is absolutely a nit pick, but would like to see a few more typescript eslint rules being enabled 😅

---

Note: The "suggestion" doesn't apply cleanly as the import from @eslint/js would be duplicated and a few more changes would be needed for everything to work 😅

[Janina Wibker (JaninaWibkerQC)]

This shouldn't be necessary. In almost all cases you don't actually have to disable eslint rules. Small changes to your types will most likely fix the issue.

[Janina Wibker (JaninaWibkerQC)]

I suspect this will be done in a PR stacked on top of this one so this might not really be that applicable, but I'll mention it anyway:

Use a reset stylesheet. This is something tailwind gives you by default, so I suspect this is just an artifact of how the stacked PRs got split up.

With tailwind (or a reset stylesheet) you don't need to include this.