Fix SSR compatibility and module bundling issues of Nuxt#483
Fix SSR compatibility and module bundling issues of Nuxt#483DonOmalVindula merged 3 commits intoasgardeo:mainfrom
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRefactors Node.js ESM imports for SSR compatibility in the browser package and consolidates TypeScript type augmentations from a separate generated file into the source module for the Nuxt package, ensuring proper typing inclusion in the published distribution. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/browser/esbuild.config.mjs (1)
49-71:⚠️ Potential issue | 🟠 MajorSplit
bannerandfooterby output format—CJS build will fail withimportstatement in banner.Lines 49-71 define a shared
commonOptionsobject with a banner (line 51) containing ESM syntax (import { Buffer } from 'buffer/index.js') and a footer (line 69) containing CJS syntax (require('buffer/index.js')). Both builds at lines 92–104 reuse this object regardless of format.When
format: 'cjs'is used, the ESMimportstatement in the banner will cause a runtime SyntaxError because import declarations cannot coexist with prior CommonJS content in the same output.Move
bannerandfooterout ofcommonOptionsand define them per-build with format-appropriate syntax:Proposed fix
const commonOptions = { - banner: { - js: ` - import { Buffer } from 'buffer/index.js'; - if (typeof window !== 'undefined' && !window.Buffer) { - window.Buffer = Buffer; - } - `, - }, bundle: true, @@ - footer: { - js: ` - if (typeof window !== 'undefined' && !window.Buffer) { - window.Buffer = require('buffer/index.js').Buffer; - } - `, - }, platform: 'browser', @@ await esbuild.build({ ...commonOptions, + banner: { + js: ` + import { Buffer } from 'buffer/index.js'; + if (typeof window !== 'undefined' && !window.Buffer) { + window.Buffer = Buffer; + } + `, + }, format: 'esm', outfile: 'dist/index.js', sourcemap: true, }); await esbuild.build({ ...commonOptions, + banner: { + js: ` + const { Buffer } = require('buffer/index.js'); + if (typeof window !== 'undefined' && !window.Buffer) { + window.Buffer = Buffer; + } + `, + }, format: 'cjs', outfile: 'dist/cjs/index.js', sourcemap: true, });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/browser/esbuild.config.mjs` around lines 49 - 71, The shared commonOptions currently embeds both an ESM-style banner (import { Buffer } ...) and a CJS-style footer (require(...)) which breaks the CJS build; move banner and footer out of commonOptions and set them per-build based on the build format (e.g., when creating the CJS build use a CJS-safe banner/footer using require and for the ESM build use the import-based banner/footer), updating the code that constructs each build (the logic around where commonOptions is spread into the per-build config) so each config supplies its own banner/footer instead of inheriting both from commonOptions.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In `@packages/browser/esbuild.config.mjs`:
- Around line 49-71: The shared commonOptions currently embeds both an ESM-style
banner (import { Buffer } ...) and a CJS-style footer (require(...)) which
breaks the CJS build; move banner and footer out of commonOptions and set them
per-build based on the build format (e.g., when creating the CJS build use a
CJS-safe banner/footer using require and for the ESM build use the import-based
banner/footer), updating the code that constructs each build (the logic around
where commonOptions is spread into the per-build config) so each config supplies
its own banner/footer instead of inheriting both from commonOptions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 89952668-81e2-4d53-82b7-d23936471bf1
📒 Files selected for processing (7)
.changeset/lemon-trams-mix.mdpackages/browser/esbuild.config.mjspackages/nuxt/.npmignorepackages/nuxt/src/module.tspackages/nuxt/src/runtime/plugins/asgardeo.tspackages/nuxt/src/runtime/server/plugins/asgardeo-ssr.tspackages/nuxt/src/runtime/types/augments.d.ts
💤 Files with no reviewable changes (3)
- packages/nuxt/.npmignore
- packages/nuxt/src/runtime/server/plugins/asgardeo-ssr.ts
- packages/nuxt/src/runtime/types/augments.d.ts
🦋 Changeset detectedThe changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. |
3 participants
Purpose
Related Issues
Related PRs
Checklist
Security checks
Summary by CodeRabbit
Bug Fixes
Chores