Skip to content

Conversation

@Hamed-Ajaj
Copy link

@Hamed-Ajaj Hamed-Ajaj commented Nov 28, 2025

Summary

This PR refactors the build system by extracting duplicated logic from dev.js and Rollup’s build-shared.js into a new shared helper module scripts/build-shared.js.

What this PR does

  • Creates a new shared module scripts/build-shared.js that exports:
    • resolveDefines
    • resolveExternal
    • resolveEntryFile
    • resolveOutputFormat
    • resolvePostfix
  • Updates dev.js to use the new shared helper functions.
  • Removes duplicated logic across the build system.
  • Ensures consistent behavior between development (esbuild) and production (Rollup).

Benefits

  • Eliminates duplicated code between dev and prod build scripts.
  • Creates a single source of truth for build-related utilities.
  • Makes the build system easier to maintain and reason about.

I ran tests and simple benchmarks on my machine and observed no noticeable performance difference compared to the current implementation.

This refactor addresses an existing TODO in the build scripts related to extracting shared build logic (line 73) .

Summary by CodeRabbit

Release Notes

  • Refactor
    • Reorganized and consolidated internal build utilities into a centralized, reusable module to reduce code duplication across build configuration and development scripts. Build logic has been standardized for improved system maintainability. These infrastructure-level changes do not affect generated artifacts, features, or end-user functionality.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Nov 28, 2025

Walkthrough

The pull request consolidates duplicated build configuration logic from rollup.config.js and scripts/dev.js into a new shared module (scripts/build-shared.js). Seven utility functions handle external module resolution, defines generation, entry file selection, output format mapping, and CJS ignore lists. Both build configs now import and use these shared utilities instead of maintaining inline implementations.

Changes

Cohort / File(s) Change Summary
Build shared utilities module
scripts/build-shared.js
New file introducing 7 exported utility functions: resolveExternal, getConsolidateDeps, resolveCJSIgnores, resolveDefines, resolveOutputFormat, resolvePostfix, and resolveEntryFile. Consolidates reusable build configuration logic with support for multiple formats, targets, and build modes.
Rollup build configuration
rollup.config.js
Imports and replaces inline logic with shared utilities: resolveEntryFile for entry resolution, resolveDefines for compile-time defines, resolveExternalShared for external modules, and resolveCJSIgnores for CommonJS ignores. Removes redundant per-format branching.
Dev build configuration
scripts/dev.js
Imports and replaces inline logic with shared utilities: resolveOutputFormat for output format mapping, resolvePostfix for runtime postfix adjustment, resolveExternal for external modules, and resolveDefines for compile-time defines. Reduces in-file conditional logic.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

  • Straightforward refactoring following consistent pattern across files
  • New utility functions are individual, testable pieces with moderate conditional logic
  • Primary concern: verify that all edge cases and environment-specific behavior from original inline implementations are correctly preserved in shared functions
  • Check parameter passing consistency between calling sites and utility signatures

Poem

🐰 Build logic scattered here and there,
Now consolidated with care!
Shared utilities, clean and bright—
Duplication done, configs unite. ✨
One source of truth, no more despair!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main refactoring: extracting shared build helpers into a new build-shared.js module. It's concise, specific, and clearly communicates the primary intent of the changeset.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@netlify
Copy link

netlify bot commented Nov 28, 2025

Deploy Preview for vue-sfc-playground failed. Why did it fail? →

Name Link
🔨 Latest commit cb52fdb
🔍 Latest deploy log https://app.netlify.com/projects/vue-sfc-playground/deploys/6929d946f7eb3500085e0d63

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
scripts/build-shared.js (2)

113-166: Double‑check that shared define semantics (SSR/BROWSER/compat) match previous behavior

The consolidated resolveDefines helper looks consistent and expressive, but it centralizes several subtle flags (__BROWSER__, __SSR__, __COMPAT__, feature flags) that were previously inlined:

  • __BROWSER__ now depends on (isGlobalBuild || isBrowserESMBuild || isBundlerESMBuild) && !enableNonBrowserBranches.
  • __SSR__ is derived solely from !isGlobalBuild.

Given how widely these flags are used in the runtime/compiler, it’s worth confirming these expressions exactly preserve the prior Rollup logic, especially for esm-browser and esm-bundler formats and compat builds.


190-205: Entry resolution for compat vs non‑compat packages appears correct

resolveEntryFile distinguishes:

  • runtime vs full builds via /runtime$/,
  • ESM browser/bundler compat builds (src/esm-runtime.ts / src/esm-index.ts),
  • all others via src/runtime.ts / src/index.ts.

This matches how compat entries are typically specialized while keeping the API simple. Consider adding a brief comment noting which formats are expected to use the ESM compat entries to help future maintainers.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 25ebe3a and cb52fdb.

📒 Files selected for processing (3)
  • rollup.config.js (3 hunks)
  • scripts/build-shared.js (1 hunks)
  • scripts/dev.js (5 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
scripts/dev.js (1)
scripts/build-shared.js (6)
  • resolveOutputFormat (173-177)
  • resolvePostfix (184-188)
  • external (41-41)
  • resolveExternal (17-77)
  • defines (143-163)
  • resolveDefines (124-166)
rollup.config.js (1)
scripts/build-shared.js (3)
  • resolveEntryFile (196-206)
  • resolveDefines (124-166)
  • resolveCJSIgnores (97-111)
🔇 Additional comments (8)
scripts/build-shared.js (3)

17-77: External resolution logic is coherent and matches the described build modes

The resolveExternal implementation cleanly separates:

  • global/browser/compat builds (early-return tree‑shaken deps only) and
  • cjs/esm‑bundler builds with dependency/peerDependency externals and compiler‑sfc extras (including consolidate deps and Node/bundler‑only packages).

This aligns with the intent to centralize external handling and should be reusable across both Rollup and dev builds without obvious regressions.


79-111: Graceful consolidate dependency handling and CJS ignore list look solid

getConsolidateDeps safely falls back to [] when @vue/consolidate is absent, and resolveCJSIgnores composes the same consolidate‑derived list with additional Node‑only packages for compiler-sfc. This matches how the externals are built and avoids hard failures when consolidate isn't installed.


168-188: Output format and postfix helpers correctly capture existing conventions

resolveOutputFormat and resolvePostfix nicely encode:

  • global/global‑runtime → iife
  • cjs → cjs
  • other formats → esm
  • *-runtimeruntime.<baseFormat>

This matches the naming scheme used in rollup.config.js and is a good centralization; no issues spotted.

scripts/dev.js (2)

14-19: Shared output format/postfix helpers are correctly integrated

The dev script now uses resolveOutputFormat(format) and resolvePostfix(format) instead of duplicating logic, which keeps esbuild output and filenames aligned with Rollup’s conventions (global*iife, *-runtimeruntime.<base>). No functional issues here.

Also applies to: 51-53


100-107: Shared define resolution keeps dev and Rollup flags consistent

Using resolveDefines({ pkg, format, target, prod, commit: 'dev' }) and passing the result directly into esbuild’s define unifies dev‑time flags with the Rollup build pipeline. This reduces drift in things like __VERSION__, __DEV__, and feature flags between environments; the hardcoded commit: 'dev' also matches prior dev behavior.

Also applies to: 120-120

rollup.config.js (3)

18-23: Entry resolution now correctly centralized via resolveEntryFile

Importing resolveEntryFile and using:

const entryFile = resolveEntryFile(format, isCompatPackage)
// ...
input: resolve(entryFile),

is a clean extraction of the previously inlined entry selection logic (runtime vs full, compat ESM vs non‑compat). This should make future tweaks to compat/runtime entry mapping much easier.

Also applies to: 164-166, 260-262


167-188: Shared define generation is wired correctly with existing override behavior

resolveDefine() now seeds replacements from resolveDefines({ pkg, format, target, prod, version: masterVersion, commit }), and the later loop still allows environment variables to override any of those keys before passing them into the esbuild plugin.

This preserves the previous override semantics while centralizing the core define logic in build-shared.js.

Also applies to: 274-280


227-238: External resolution and CJS ignores are cleanly delegated to shared helpers

  • resolveExternal() now forwards pkg, format, process.env.TARGET, and the computed isGlobalBuild, isBrowserESMBuild, isCompatPackage, and packageOptions into resolveExternalShared, so Rollup and dev builds share the same external rules.
  • resolveNodePlugins() derives cjsIgnores via resolveCJSIgnores(process.env.TARGET) and feeds that into the commonjs plugin’s ignore option, matching the externals logic for compiler-sfc.

This consolidation removes a lot of bespoke Rollup‑only wiring without changing behavior in an obvious way.

Also applies to: 240-255

Comment on lines +71 to +82
// resolve externals using shared function
const external = inlineDeps
? []
: resolveExternal({
pkg,
format,
target,
isGlobalBuild: format === 'global',
isBrowserESMBuild: format.includes('esm-browser'),
isCompatPackage: target === 'vue-compat',
packageOptions: pkg.buildOptions || {},
})
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Align dev isGlobalBuild with Rollup for runtime formats

The dev external resolution now delegates to resolveExternal, but:

isGlobalBuild: format === 'global',

while Rollup derives isGlobalBuild from /global/.test(format), which also treats global-runtime as a global build.

If scripts/dev.js is ever invoked with format=global-runtime, externals for that mode will differ from Rollup (notably around treeShakenDeps handling). To keep dev and production behavior in sync, consider switching this to the same predicate, e.g.:

-        isGlobalBuild: format === 'global',
+        isGlobalBuild: format.startsWith('global'),

(or mirroring whatever check Rollup uses).

🤖 Prompt for AI Agents
In scripts/dev.js around lines 71 to 82, the dev external resolution uses a
strict equality check isGlobalBuild: format === 'global' which diverges from
Rollup's /global/.test(format) (so formats like 'global-runtime' are treated
differently); change the predicate to mirror Rollup (e.g. use a regex test like
/global/.test(format>)) so isGlobalBuild is true for any format containing
"global", ensuring externals and treeShakenDeps behavior match Rollup's
runtime/global handling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant