Reviewing files that changed from the base of the PR and between fe9bcd2 and 43d99ee.

• package-lock.json is excluded by !**/package-lock.json

• lerna.json (1 hunks)
• packages/cli-utils/package.json (2 hunks)
• packages/cli/package.json (2 hunks)
• packages/gatsby-plugin/package.json (2 hunks)
• packages/html-templates/package.json (2 hunks)
• packages/next-plugin/package.json (2 hunks)
• packages/plugin-webpack-filter/package.json (1 hunks)
• packages/plugin-webpack-validate/package.json (1 hunks)
• packages/rollup-plugin/package.json (2 hunks)
• packages/ui/package.json (2 hunks)
• packages/utils/package.json (2 hunks)
• packages/webpack-plugin/package.json (2 hunks)

• packages/plugin-webpack-validate/package.json
• packages/plugin-webpack-filter/package.json
• packages/ui/package.json

• GitHub Check: webpack5 plugin ubuntu-latest nodejs 14
• GitHub Check: webpack4 plugin ubuntu-latest nodejs 14
• GitHub Check: webpack5 plugin ubuntu-latest nodejs 16
• GitHub Check: webpack4 plugin ubuntu-latest nodejs 16
• GitHub Check: webpack5 plugin ubuntu-latest nodejs 18
• GitHub Check: webpack5 plugin ubuntu-latest nodejs 20
• GitHub Check: webpack5 plugin windows-latest nodejs 14
• GitHub Check: webpack4 plugin windows-latest nodejs 14
• GitHub Check: test-unit
• GitHub Check: rollup 4 plugin nodejs 18
• GitHub Check: CLI ubuntu-latest nodejs 14
• GitHub Check: test-e2e
• GitHub Check: rollup 3 plugin nodejs 16
• GitHub Check: lint
• GitHub Check: CLI ubuntu-latest nodejs 16
• GitHub Check: CLI ubuntu-latest nodejs 18
• GitHub Check: CLI ubuntu-latest nodejs 20
• GitHub Check: webpack5 plugin windows-latest nodejs 14
• GitHub Check: webpack4 plugin windows-latest nodejs 14
• GitHub Check: test-e2e

packages/next-plugin/package.json (1)

3-3: LGTM! Correct versioning approach for pre-release.

The change to use exact version for the alpha dependency is the right approach, as it prevents unexpected behavior during the pre-release phase.

Also applies to: 41-41

packages/gatsby-plugin/package.json (1)

3-3: LGTM! Consistent with other packages.

Also applies to: 41-41

packages/webpack-plugin/package.json (1)

3-3: Verify test coverage for the fix.

Since this is a core package that others depend on, please ensure that the test suite (particularly test:package) passes and covers the Vite maximum call stack issue scenario.

Run the following script to check test coverage:

Also applies to: 48-49

packages/utils/package.json (1)

3-3: Verify TypeScript builds for both CJS and ESM.

Since this package provides both CommonJS and ESM builds with TypeScript types, please ensure both build outputs work correctly with the changes.

Run the following script to verify the builds:

Also applies to: 38-39

✅ Verification successful

TypeScript dual-build configuration verified successfully

The package has a robust TypeScript setup with:

• Separate build configurations for CommonJS (lib/) and ESM (lib-esm/)
• Clean type definitions without circular dependencies
• Proper type declaration output handling

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check TypeScript build outputs and potential recursion issues

# Look for recursive type definitions that might cause stack overflow
rg -l "type.*=.*\1" src/
# Check if there are any circular dependencies in type definitions
ast-grep --pattern 'import { $_ } from "$_"' src/

Length of output: 318

---

Script:

#!/bin/bash
# Check TypeScript and build configuration
echo "=== TypeScript Config ==="
fd tsconfig.json
cat packages/utils/tsconfig.json 2>/dev/null || echo "No tsconfig.json found"

echo -e "\n=== Package Build Configuration ==="
cat packages/utils/package.json

echo -e "\n=== Checking for Circular Dependencies ==="
# Look for potential circular imports in TypeScript files
fd -e ts -e tsx . packages/utils/src 2>/dev/null && \
  rg --type ts "^import.*from.*" packages/utils/src

echo -e "\n=== Type Definition Patterns ==="
# Look for type definitions
rg --type ts "^(export )?type" packages/utils/src

Length of output: 18460

packages/rollup-plugin/package.json (1)

3-3: Version changes need clarification regarding the Vite issue.

The package version is being updated from 4.18.0 to 4.18.1-alpha.0, and dependencies are being pinned to specific pre-release versions. However, it's unclear how these version changes address the reported Vite maximum call stack size issue mentioned in the PR objectives.

Could you please clarify:

1. How do these version changes resolve the Vite issue?
2. Are there any breaking changes in this alpha release?
3. Should we consider a patch version (4.18.1) instead of an alpha release for a bug fix?

Also applies to: 48-49

packages/cli-utils/package.json (1)

3-3: Dependencies are being strictly pinned to alpha versions.

The change removes the caret (^) prefix from dependency versions, which means:

1. No automatic minor version updates
2. All packages must be exactly on 4.18.1-alpha.0

This strict pinning might cause issues if other packages in the ecosystem need flexibility in version resolution. Consider whether this strict pinning is necessary for fixing the Vite issue.

Also applies to: 40-42

packages/cli/package.json (1)

3-3: Consistent version updates across packages.

The version changes are consistent with other packages, moving to 4.18.1-alpha.0. However:

1. The package has a direct dependency on core-js with a caret range (^3.21.0), while other dependencies are strictly pinned. This inconsistency in version pinning strategy should be reviewed.
2. Run the following script to verify version consistency across all package.json files:

Also applies to: 54-57

packages/html-templates/package.json (2)

3-3: Review the necessity of alpha release for devDependencies.

The package is using alpha versions (4.18.1-alpha.0) of @bundle-stats/ui and @bundle-stats/utils as devDependencies. Since these are development dependencies:

1. Consider whether these need to be strictly pinned
2. Evaluate if moving devDependencies to alpha versions is necessary for the Vite fix

Also applies to: 33-34

---

3-3: Verify the impact on build stability.

Moving multiple packages to alpha versions simultaneously could impact build stability.

Run the following script to check for any existing issues or discussions about version-related problems:

Also applies to: 33-34

✅ Verification successful

Coordinated alpha release strategy reduces build stability risks

All packages in the monorepo are being moved to version 4.18.1-alpha.0 in a coordinated manner, with properly aligned internal dependencies. The consistent versioning across packages actually helps maintain build stability by preventing version mismatches.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Search for version-related issues and discussions
gh issue list --search "4.18.0 4.18.1 in:title,body" --state all --limit 10
gh pr list --search "4.18.0 4.18.1 in:title,body" --state all --limit 10

Length of output: 440

---

Script:

#!/bin/bash
# Check for alpha versions and version constraints across package files
echo "=== Searching for alpha versions in package.json files ==="
fd package.json --exec grep -l "alpha" {} \; | while read -r file; do
    echo "=== $file ==="
    grep -A 2 "version\|peerDependencies\|dependencies" "$file"
done

echo -e "\n=== Checking package-lock.json for html-templates ==="
fd package-lock.json --exec grep -A 5 "html-templates" {} \;

Length of output: 6320