Add Vue integration test with 1000 components#20055
Conversation
WalkthroughThis PR updates the Vue Vite integration test file to expand test coverage. It imports a 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Warning Review ran into problems🔥 ProblemsStopped waiting for pipeline failures after 30000ms. One of your pipelines takes longer than our 30000ms fetch window to run, so review may not consider pipeline-failure results for inline comments if any failures occurred after the fetch window. Increase the timeout if you want to wait longer or run a Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
integrations/vite/vue.test.ts (1)
168-173: ⚡ Quick winStrengthen the assertion to cover the 1000-component upper bound.
This test’s purpose is a 1,000-component stress case, but current checks stop at
component-99. Add at least one near-tail index (for example999) so truncation/regression past the first 100 components is caught.Proposed diff
await fs.expectFileToContain(files[0][0], [ candidate`content-['component-0']`, candidate`component-0`, candidate`content-['component-99']`, candidate`component-99`, + candidate`content-['component-999']`, + candidate`component-999`, ])🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@integrations/vite/vue.test.ts` around lines 168 - 173, The test currently asserts presence of only up to component-99, so extend the fs.expectFileToContain call (the array passed to fs.expectFileToContain in the test) to include a near-tail index such as candidate`content-['component-999']` and candidate`component-999` (alongside the existing entries) so the 1,000-component stress case verifies elements near the end and catches truncation/regressions; update the array in the await fs.expectFileToContain(files[0][0], [...]) invocation accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@integrations/vite/vue.test.ts`:
- Around line 168-173: The test currently asserts presence of only up to
component-99, so extend the fs.expectFileToContain call (the array passed to
fs.expectFileToContain in the test) to include a near-tail index such as
candidate`content-['component-999']` and candidate`component-999` (alongside the
existing entries) so the 1,000-component stress case verifies elements near the
end and catches truncation/regressions; update the array in the await
fs.expectFileToContain(files[0][0], [...]) invocation accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0f708ed2-c7bb-4714-9f52-39b96a3414bc
📒 Files selected for processing (1)
integrations/vite/vue.test.ts
Confidence Score: 5/5This PR only adds a new integration test and a minor fix to an existing test — no production code is touched. The change is purely additive test infrastructure. The new test correctly exercises the @reference + @apply with 1000 components scenario, assertions cover components 0, 99, and 999 (spanning the full range), dependency installation and build comfortably fit within the default 60 s timeout, and path resolution for @reference '../main.css' from src/components/ is correct. No files require special attention. Reviews (2): Last reviewed commit: "Update integrations/vite/vue.test.ts" | Re-trigger Greptile |
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
This PR adds an integration test with Vue where we use a 1000 components and where each component references a CSS file via
@reference. Each component has a unique class that uses@apply.There are some discussions in #16429 that mention that this causes OOM issues. Right now I can't reproduce that, and even with a 1000 components, it produces CSS in a reasonable time:
I also started a Vite server and triggered file changes to see if the memory would grow forever, which it didn't. After a 1000 changes, everything still behaves smoothly:

Making changes manually to a single component, result in proper HMR request that update the browser:
Screen.Recording.2026-05-14.at.15.06.03.mov
This test is here to make sure that it keeps working in the future.
If I remove all
@referencereferences, and usages of@apply, then the build time is indeed faster:So we go from
1.97s→3.17s, which is a1.2sincrease when you use@referencewith@applyin 1000 files for a fresh build.I also saw some comments about the CSS growing whenever
@referencewas used, but as you can see in the snippets above they are at a stable size.Test plan
[ci-all] For testing on Windows / macOS