fix: exclude asyncapi-ui.min.js from transpilation to prevent Babel deoptimisation warning

[lightning-sagar]

Description

This PR fixes the long-standing Babel warning:

[BABEL] Note: The code generator has deoptimised the styling of asyncapi-ui.min.js as it exceeds the max of 500KB

The issue occurs because the React transpiler processes asyncapi-ui.min.js, which is a large minified dependency that should not be transpiled.

What was changed

• Updated the React SDK transpiler to ignore asyncapi-ui.min.js before passing files to Rollup/Babel.

• Implemented a simple filter:

  files = files.filter(f => !f.endsWith("asyncapi-ui.min.js"));
  

  (and equivalent logic where needed)

• After applying the fix, the generator runs without any Babel deoptimisation warnings.

📌 Additional note

The old repo (asyncapi-archived-repos/generator-react-sdk) is archived, so this change was made in the active path:

apps/react-sdk/src/transpiler/transpiler.ts

Related issue(s)

Fixes: #1771 #717

Summary by CodeRabbit

• Bug Fixes
  • Reduced noisy build output by suppressing non-debug tool messages during normal runs.
  • Collected and surfaced build warnings only when running in debug mode for clearer diagnostics.
  • Ensured standard error output, warning handling, and build resources are reliably restored/closed after the transpile step.

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

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: e2fc5b897de694f58c6c3fd9bfac1bca79ba4e4e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai[bot]]

Walkthrough

Suppresses non-debug Babel "[BABEL]" stderr output during transpilation by temporarily overriding process.stderr.write, collects Rollup warnings into an array via an onwarn handler, restores stderr.write with a try/finally, conditionally logs warnings when --debug is present, and calls bundles.close() after transpile.

Changes

Cohort / File(s)

Summary

Transpiler runtime logging & warnings apps/react-sdk/src/transpiler/transpiler.ts

Imported log from loglevel and RollupWarning typing; added warnings array and --debug detection; temporarily override process.stderr.write to filter [BABEL] messages when not debugging; wrapped transpile flow in try/finally to restore original stderr.write; replaced no-op onwarn with handler that collects warnings; conditionally logs collected warnings in debug mode; added explicit bundles.close() call.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Review focus:
  • Correctness and thread-safety of overriding/restoring process.stderr.write (async calls, nested invocations).
  • Coverage and accuracy of the [BABEL] filter (possible false positives/negatives).
  • Ensuring collected Rollup warnings are surfaced appropriately and bundles.close() always runs.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 2 inconclusive)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The PR title mentions excluding asyncapi-ui.min.js but the actual changes focus on warning suppression and debug logging, not exclusion.	The actual implementation suppresses Babel warnings via debug mode rather than filtering files. Update the title to reflect the actual approach, e.g., 'fix: suppress Babel deoptimisation warnings in debug mode' or implement file exclusion as originally stated.
Linked Issues check	❓ Inconclusive	The PR partially addresses issue #1771 by suppressing warnings, but the approach diverges from the stated objective to exclude asyncapi-ui.min.js from transpilation.	Clarify with maintainers whether suppressing warnings via --debug flag meets the issue requirements, or if excluding the file from transpilation is the intended solution per PR objectives.
Out of Scope Changes check	❓ Inconclusive	The changes include debug logging infrastructure and warning collection that go beyond the stated objective of excluding asyncapi-ui.min.js.	Review whether the debug mode and stderr interception are necessary scope additions or if a simpler file exclusion approach would be more appropriate.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ 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

• X
• Mastodon
• Reddit
• LinkedIn

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

[asyncapi-bot]

What reviewer looks at during PR review

The following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.

1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

   Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

   Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

[lightning-sagar]

@derberg , i noticed Babel prints warnings directly to stderr, so Rollup doesnot catch them, to follow your suggestion, i modified the transpiler so:

• babel warning are suppressed by default and
• they only appear when the generator is run with --debug flag

is this the right approach or would you prefer a different way of handling these warnings??

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud