(wip) Add lighthouse CI#65
Conversation
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds a Lighthouse CI workflow, LHCI config, a package script, and .gitignore entry; updates demo HTML to namespace Tailwind config and defer its script load. The workflow builds the repo and demo, runs LHCI autorun, computes/report paths, and uploads Lighthouse reports and artifacts. Changes
Sequence Diagram(s)sequenceDiagram
participant GH as GitHub Actions
participant Runner as CI Runner
participant Repo as Repository
participant Node as Node/Yarn
participant Build as Build Steps
participant LHCI as @lhci/cli
participant FS as Filesystem
participant Upload as upload-artifact
GH->>Runner: triggered on push to main or PR
Runner->>Repo: checkout
Runner->>Node: setup Node 22.x + yarn cache
Runner->>Node: yarn install --frozen-lockfile
Runner->>Build: yarn build
Runner->>Build: yarn build:demo --base=/react-mentions-ts/
Build->>LHCI: npx @lhci/cli@0.15.x autorun (reads lighthouserc.cjs)
LHCI-->>Runner: writes .lighthouseci/ and ./lighthouse-reports
Runner->>Upload: upload-artifact name=lighthouse-reports path=${{ steps.outputs.reportsPath }}
Runner->>Upload: upload-artifact name=lighthouse-artifacts path=${{ steps.outputs.resultsPath }}
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary of ChangesHello @hbmartin, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request integrates Lighthouse CI into the project, establishing an automated process for auditing the web application's quality metrics. The primary goal is to continuously monitor and ensure high standards for performance, accessibility, and best practices within the demo environment, providing early feedback on potential regressions or improvements. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #65 +/- ##
=======================================
Coverage 83.20% 83.20%
=======================================
Files 35 35
Lines 1280 1280
Branches 292 292
=======================================
Hits 1065 1065
Misses 97 97
Partials 118 118 🚀 New features to boost your workflow:
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces Lighthouse CI to the project, which is a great step for monitoring performance. I've added a couple of suggestions: one to improve the stability of the Lighthouse reports by adjusting the number of runs, and a critical fix for the lighthouse script in package.json which currently uses a non-existent version of @lhci/cli and would fail.
| "clean": "rimraf dist", | ||
| "build": "yarn clean && tsup --config tsup.config.ts", | ||
| "build:demo": "vite build --config demo/vite.config.ts", | ||
| "lighthouse": "yarn build:demo && npx @lhci/cli@0.15.x autorun", |
There was a problem hiding this comment.
The specified version 0.15.x for @lhci/cli does not exist on npm, which will cause this script to fail. The latest version is 0.13.0.
For better dependency management, I recommend adding @lhci/cli to your devDependencies (yarn add -D @lhci/cli@^0.13.0). This will ensure version consistency across all environments.
| "lighthouse": "yarn build:demo && npx @lhci/cli@0.15.x autorun", | |
| "lighthouse": "yarn build:demo && npx @lhci/cli@^0.13.0 autorun", |
| ci: { | ||
| collect: { | ||
| staticDistDir: 'demo/dist', | ||
| numberOfRuns: 2, |
There was a problem hiding this comment.
To get more stable Lighthouse scores, it's recommended to use an odd number of runs (like 3 or 5) to calculate a median. With 2 runs, you're getting an average, which can be more susceptible to outliers. The default value for this property is 3.
| numberOfRuns: 2, | |
| numberOfRuns: 3, |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
lighthouserc.js (1)
5-7: Consider reducing the server ready timeout.The
startServerReadyTimeoutis set to 120 seconds (2 minutes), which is quite long for serving a static demo site. Typical static sites are ready almost immediately.Consider reducing this to 30 seconds unless there's a specific reason for the extended timeout:
collect: { staticDistDir: 'demo/dist', numberOfRuns: 2, - startServerReadyTimeout: 120_000, + startServerReadyTimeout: 30_000, },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/lighthouse.yml(1 hunks).gitignore(2 hunks)lighthouserc.js(1 hunks)package.json(1 hunks)
🧰 Additional context used
🪛 GitHub Actions: Lighthouse CI
lighthouserc.js
[error] 2-2: ReferenceError: module is not defined in ES module scope. This file is treated as an ES module but uses CommonJS 'module' syntax.
🔇 Additional comments (4)
.gitignore (1)
6-6: LGTM!Both additions are appropriate for ignoring CI artifacts generated by the Lighthouse CI workflow and build tooling.
Also applies to: 17-17
.github/workflows/lighthouse.yml (2)
1-11: LGTM!The workflow configuration is appropriate, triggering on main branch pushes and pull requests to catch performance regressions early.
12-28: Verify repository setup: Lighthouse CI GitHub App token must be configured before workflow can post status checks.The LHCI_GITHUB_APP_TOKEN should be obtained by authorizing the Lighthouse CI GitHub App and copying the token provided on the authorization page, then adding it to your build environment as a repository secret. Without this secret, the workflow will execute but status checks from Lighthouse will not appear on pull requests.
The workflow code itself is correct. This is a prerequisite setup task—ensure the Lighthouse CI GitHub App is installed and the token is added to the repository secrets before relying on PR status checks.
package.json (1)
41-41: Version constraint is current.The latest version of @lhci/cli is 0.15.1 (published June 25, 2025), and the script's
0.15.xconstraint correctly resolves to this version while maintaining stability across patch releases.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
lighthouserc.cjs (1)
1-19: Solid Lighthouse CI configuration!The configuration follows best practices with appropriate preset selection and PWA disabled for a library demo. The setup will effectively monitor performance regressions.
One optional optimization: the
startServerReadyTimeoutof 120 seconds (line 7) seems excessive for serving static files. For a static demo build, 30-45 seconds is typically sufficient.Consider reducing the timeout:
- startServerReadyTimeout: 120_000, + startServerReadyTimeout: 30_000,
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/workflows/lighthouse.yml(1 hunks)demo/index.html(2 hunks)lighthouserc.cjs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/lighthouse.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: lighthouse
🔇 Additional comments (2)
demo/index.html (2)
8-9: LGTM! Proper Tailwind config namespacing.The defensive initialization and explicit window namespacing prevents potential conflicts and aligns with Tailwind CDN best practices.
25-25: Excellent performance optimization!Deferring the Tailwind CSS script load prevents render-blocking and will positively impact Lighthouse performance scores.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
.github/workflows/lighthouse.yml (2)
29-29: Make the demo base path configurable or document the assumption.The hardcoded base path
/react-mentions-ts/assumes the demo will always be served from this path. If the demo might be served from a different location (e.g., in staging or production), consider making this configurable via a workflow input or environment variable. Otherwise, add a comment explaining why this path is fixed.
33-35: Document the required LHCI_GITHUB_APP_TOKEN secret.The workflow references the
LHCI_GITHUB_APP_TOKENsecret, but there's no documentation in the repo (e.g., in a CONTRIBUTING or workflow setup guide) about how to configure this secret. Consider adding a comment or updating your CONTRIBUTING guide to explain how maintainers should set up this token.Would you like me to help generate documentation or a setup guide for the LHCI token?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/lighthouse.yml(1 hunks)lighthouserc.cjs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- lighthouserc.cjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: lighthouse
🔇 Additional comments (3)
.github/workflows/lighthouse.yml (3)
32-32: Verify the DEBUG pattern intent.The debug environment variable
DEBUG=lhci:*,-*:verboseexcludes any logger suffixed with:verbose, which may inadvertently suppress important warnings and diagnostic output. Confirm this is intentional; if you want full logging, useDEBUG=lhci:*instead.
42-44: Verify both artifact paths exist and are necessary.The workflow uploads artifacts from
.lighthouseci/andlighthouse-reports/. Confirm that both paths are created by Lighthouse CI and are necessary for your reporting needs. If only one is generated, remove the unused path to avoid upload warnings.
1-44: Good foundation for Lighthouse CI integration.The workflow structure is solid: frozen lockfile ensures reproducibility, artifact upload on all outcomes aids debugging, and the multi-step build approach is appropriate. Verify the Lighthouse configuration in
lighthouserc.cjsincludes proper audit budgets or collection settings so the CI adds value beyond data collection.
… directory from lighthouserc.cjs,
ensures both .lighthouseci and the configured reports folder exist, re-runs lhci upload when
the filesystem target isn’t populated yet, and records both paths in step outputs for downstream
use .github/workflows/lighthouse.yml:33-55.
- Artifact uploads now rely on those outputs, eliminating hard‑coded paths that didn’t match the config
and caused the “path required” failure .github/workflows/lighthouse.yml:63-73.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/lighthouse.yml (1)
39-43: Simplify and harden the config extraction logic.The inline Node.js code that reads
lighthouserc.cjsis fragile. It relies onrequire()without explicit error handling and could fail if the config file has syntax errors, missing exports, or path resolution issues. Extract this logic into a dedicated helper script or use a more robust approach.Consider creating a dedicated
.jshelper file or using a simpler approach:- REPORTS_DIR=$(node -p "(() => { - const cfg = require('./lighthouserc.cjs') - const dir = (cfg && cfg.ci && cfg.ci.upload && cfg.ci.upload.outputDir) || 'lighthouse-reports' - return dir.startsWith('./') ? dir.slice(2) : dir - })()") + REPORTS_DIR=$(node -e " + try { + const cfg = require('./lighthouserc.cjs'); + const dir = (cfg?.ci?.upload?.outputDir) || 'lighthouse-reports'; + console.log(dir.startsWith('./') ? dir.slice(2) : dir); + } catch (e) { + console.log('lighthouse-reports'); + } + ")This adds basic error handling to fall back to a default directory if config parsing fails.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/lighthouse.yml(1 hunks)lighthouserc.cjs(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- lighthouserc.cjs
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: lighthouse
🔇 Additional comments (2)
.github/workflows/lighthouse.yml (2)
48-50: Clarify the conditional upload logic.The upload condition
[ -f ".lighthouseci/manifest.json" ] && [ -z "$(ls -A "$REPORTS_DIR" 2>/dev/null)" ]uploads reports only when the manifest exists and the reports directory is empty. This logic is counterintuitive—typically you'd upload when reports exist, not when they're missing. Add a comment explaining this workaround and verify it aligns with your Lighthouse CI workflow expectations.
35-35: No action required—@lhci/cli@0.15.x is current and secure.The latest stable version is 0.15.1 (published June 25, 2025), which falls within the
@0.15.xrange used in the workflow. No security advisories or direct vulnerabilities are reported for version 0.15.x. The version specification is acceptable.
| on: | ||
| push: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
Branch name mismatch: workflow triggers on main but PR target is master.
The workflow is configured to run on the main branch, but the PR indicates the target branch is master. This is a critical blocker—the workflow will not execute on the intended target branch. Verify the correct default branch name for the repository and update accordingly.
Update the workflow trigger to match your target branch:
on:
push:
branches:
- - main
+ - master
pull_request:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - main | |
| - master |
🤖 Prompt for AI Agents
In .github/workflows/lighthouse.yml around line 6 the workflow is set to trigger
on branch "main" while the PR target (and repository default) is "master";
update the workflow trigger to the correct branch name (replace "main" with
"master" or adjust to the repository's actual default branch), verify any other
branch names in the file match the repo, and commit the change so the workflow
will run on the intended target branch.
|
Looks like there are a few issues preventing this PR from being merged!
If you'd like me to help, just leave a comment, like Feel free to include any additional details that might help me get this PR into a better state. You can manage your notification settings |
1 participant
Summary by CodeRabbit
New Features
Chores