Conversation
|
Semver Impact of This PR🟢 Patch (bug fixes) 📋 Changelog PreviewThis is how your changes will appear in the changelog. Bug Fixes 🐛
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
Codecov Results 📊✅ Patch coverage is 100.00%. Project has 3639 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 75.35% 75.35% —%
==========================================
Files 115 115 —
Lines 14760 14760 —
Branches 0 0 —
==========================================
+ Hits 11121 11121 —
- Misses 3639 3639 —
- Partials 0 0 —Generated by Codecov Action |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| const { image, class: className } = Astro.props; | ||
|
|
||
| const optimized = await getImage({ | ||
| src: image, | ||
| format: 'webp', |
There was a problem hiding this comment.
Bug: The getImage() function may not prepend the base path to image URLs, causing broken images in deployments with a non-root base path, such as PR previews.
Severity: MEDIUM
Suggested Fix
Manually prepend the base path to the URL generated by getImage(). The base path can be accessed via import.meta.env.BASE_URL. Ensure the final URL is correctly constructed before being used in the inline style.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: docs/src/components/FeatureVisual.astro#L10-L14
Potential issue: The refactoring from manual URL concatenation to using Astro's
`getImage()` function introduces a potential issue in deployments with a non-root base
path. The `getImage()` function may not automatically prepend the configured `base` path
(e.g., `/pr-preview/pr-123/`) to the `src` attribute of the optimized image. This would
result in broken image links because the browser would try to fetch them from the root
of the domain. This issue would manifest in specific environments like PR previews,
which are configured to use a sub-path, while production deployments to the root domain
would appear to work correctly.
Did we get this right? 👍 / 👎 to inform future reviews.
|
|
||
| <div | ||
| class:list={['feature-visual', className]} | ||
| style={`background-image: url('${optimized.src}');`} |
There was a problem hiding this comment.
Bug: The getImage() function does not prepend the site's base path, causing background images to fail to load when the site is deployed on a subpath.
Severity: MEDIUM
Suggested Fix
Manually prepend the import.meta.env.BASE_URL to the src property of the object returned by getImage(). Ensure a trailing slash is handled correctly to construct the valid, full image path for use in the CSS url(). For example: const baseUrl = import.meta.env.BASE_URL; const base = baseUrl.endsWith('/') ? baseUrl : baseUrl + '/'; const finalSrc = base + optimized.src.replace(/^\//, '');
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: docs/src/components/FeatureVisual.astro#L21
Potential issue: The refactoring to use Astro's `getImage()` function for background
images removes the explicit handling of the site's base path. The `getImage()` function
does not automatically prepend the `base` path configured in `astro.config.mjs`.
Consequently, when the documentation site is deployed to a non-root path (e.g., for PR
previews like `/pr-preview/pr-291/`), the generated image URLs will be incorrect. The
browser will attempt to load images from the root of the domain, resulting in 404 errors
and missing background images on affected pages.
Did we get this right? 👍 / 👎 to inform future reviews.
betegon
left a comment
betegon
left a comment
There was a problem hiding this comment.
thanks man! really appreciate it <3
2 participants
Summary
The landing page was loading ~6.5 MB of unoptimized PNG background images. Files in
public/are served as-is by Astro, bypassing its image optimization pipeline entirely.This PR moves the images into
src/assets/and uses Astro'sgetImage()API to produce optimized WebP versions at build time — 93% total size reduction with zero visual change.Changes
docs/public/→docs/src/assets/so they enter Astro's optimization pipelineFeatureVisual.astro— wraps the feature section backgrounds usinggetImage()to produce WebP at build timeTerminal.astro— samegetImage()pattern for the herobg.pngindex.mdx— uses<FeatureVisual image={...}>instead of raw inlinebackground-imageURLsSize reduction
section-bg-1section-bg-2section-bg-3bgTest plan
main