docs: refresh home stats for oxlint, vite, and vitest Issue: #1511#1512
docs: refresh home stats for oxlint, vite, and vitest Issue: #1511#1512nozomee wants to merge 7 commits intovoidzero-dev:mainfrom
Conversation
✅ Deploy Preview for viteplus-preview ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
We want a way to automate the npm downloads & github stars. Otherwise the hard coded numbers will be outdated quickly. For example, vitest had 7% increase in downloads in the last week. A potential way to do this is to have a fetch data script that is executed on a schedule via github actions. The data is stored as a json in this repo, which the home pages references |
|
I’d like to take this on — I’m already actively working on it and will open a PR soon. Right now the trusted-stack numbers on the homepage are hard-coded, which means they’ll drift quickly and require repeated manual edits over time (especially with npm download velocity changing week-to-week). My planned implementation: Add a lightweight fetch script that pulls: Why this should help: Keeps homepage metrics current automatically Expected flow after merge: Merge once A few maintainer decisions may still be useful: Whether github-actions[bot] should push JSON-only updates directly to main or use PRs In short: automate the trusted-stack stats pipeline once, remove repetitive manual maintenance, and keep homepage credibility high with minimal long-term overhead. PR coming soon. |
|
@jong-kyung @mdong1909 I’ve committed the changes to address these updates, Kindly review it once! |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 23b81b2815
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…o node-version-file: .node-version
|
@jong-kyung @mdong1909 I’ve committed the changes , Kindly review it once! |
…and TypeScript migration
|
@jong-kyung @camc314 I’ve committed the changes , Kindly review it once! |
|
@codex review |
|
Codex Review: Didn't find any major issues. Breezy! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
There was a problem hiding this comment.
Could this script live under .github/scripts/?
It's CI-only and uses the same peter-evans/create-pull-request pattern as upgrade-deps.yml.
|
@nozomee Could you take a look at the failing CI? |
…ocs lockfile - Relocate fetch script to .github/scripts and update references - Fix docs deps (no catalog:), update docs pnpm-lock - Adjust docs scripts tsconfig for node/dom types
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
@jong-kyung I’ve committed the changes , Kindly review it once! |
| - name: Fetch npm and GitHub stats | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: node docs/scripts/fetch-trusted-stack-stats.ts |
There was a problem hiding this comment.
The script lives at .github/scripts/fetch-trusted-stack-stats.ts, not docs/scripts/.
There was a problem hiding this comment.
Good catch — you’re right.
I moved the fetch script to /.github/scripts/fetch-trusted-stack-stats.ts to align with the existing CI scripts (similar to upgrade-deps.yml). I’ve updated the workflow step to run:
node .github/scripts/fetch-trusted-stack-stats.ts
so it matches the actual location.
will push the changes shortly!
There was a problem hiding this comment.
Is this file actually needed? The root tsconfig.json already enables the same options
There was a problem hiding this comment.
Root tsconfig.json isn’t a good fit because it lacks DOM lib (needed for fetch) and would typecheck too much of the repo. I moved the minimal config to .github/scripts/tsconfig.json (since it’s for CI scripts) and updated the docs check script to use it; removed docs/scripts/tsconfig.json, will push the commit changes shortly.
There was a problem hiding this comment.
Root tsconfig.json isn’t a good fit because it lacks DOM lib (needed for fetch)
This script shouldn't rely on DOM lib since it'll be executing in a node env.
There was a problem hiding this comment.
Root tsconfig.json isn’t a good fit because it lacks DOM lib (needed for fetch)
This script shouldn't rely on
DOMlib since it'll be executing in a node env.
Good point — agreed. Even though the script uses fetch, it runs in Node, so it shouldn’t depend on the DOM lib.
There was a problem hiding this comment.
Are these two new devDependencies actually needed here? @types/node and typescript are already provided by the workspace root.
There was a problem hiding this comment.
I looked into this, and with our current setup it’s not really safe to remove those dependencies.
Even though typescript and @types/node exist at the workspace root, the docs/ directory is installed and locked independently (pnpm -C docs install --frozen-lockfile with its own docs/pnpm-lock.yaml). That means docs/ won’t reliably inherit root devDependencies unless we switch to a full workspace-level install.
Since docs/ also runs its own TypeScript check (update-trusted-stack-stats:check), it needs local access to tsc plus Node typings for imports and globals.
So for now, keeping typescript and @types/node in docs/package.json makes the most sense — it keeps docs/ self-contained and avoids CI or isolated install issues.
If we want to remove that duplication later, we’d first need to change the install/CI flow to rely on a root workspace install rather than pnpm -C docs.
There was a problem hiding this comment.
I think we can simplify further: the :check script isn't wired into any CI job, so it's not actually catching anything.
Could we drop:
- docs/scripts/tsconfig.json
- The update-trusted-stack-stats(:check) scripts in docs + root
- @types/node and typescript from docs/devDependencies
cc. @camc314 WDYT?
There was a problem hiding this comment.
Good point — let’s see what @camc314 thinks first, then we can figure out the best path forward from there.
Happy to help once we’ve got their input.
- Update update-trusted-stack-stats workflow to use correct script path - Move stats typecheck tsconfig under .github/scripts and remove docs/scripts/tsconfig.json - Keep docs check script pointing to the new tsconfig
|
@jong-kyung Looks like this is only a packageManager version conflict (10.33.0 vs 10.33.2). Could you check which version we want to standardize on across the repo/CI and align this accordingly? Once we confirm the intended pnpm version, we can resolve it cleanly. |
|
@nozomee On pnpm: let's stick with 10.33.0 as pinned in That said — the version mismatch you're seeing is really a lockfile drift issue, not a pnpm version issue. It only exists because If we go with the simplification (drop cc. @camc314 |
Changes made
1.
docs/.vitepress/theme/components/home/FeatureCheck.vue600+→750+(text before theESLintcode span).2.
docs/.vitepress/theme/components/home/ProductivityGrid.vue“A trusted stack to standardize on” — Vite
69m+→115m+78.7k→80.4kVitest
35m+→57m+16.1k→16.5kOXC (npm row uses
oxlintpackage downloads)5m+→5.3m+19.8k→21.0kFiles touched: 2
Net: 7 lines updated (string substitutions only; no logic or layout changes).