chore(react-sdk): use new Array() constructor instead of Array()

[dkx955]

Description

SonarCloud flags both call sites for calling Array() without new. Both take a single numeric argument, so the constructor form is behaviour preserving:

• apps/react-sdk/src/utils/withNewLines.ts:9
• apps/react-sdk/src/utils/withIndendation.ts:46

I grepped the whole repo for Array( not preceded by new and outside node_modules; these two are the only remaining occurrences in scope, so this closes the issue rather than partially addressing it.

Equivalence checked rather than assumed — Array(n).fill(x).join('') vs new Array(n).fill(x).join('') for n = 0, 1, 5, both the space and the tab/newline fill characters, identical output in every case (Array(n) and new Array(n) produce the same sparse array; .fill() then densifies it). The two forms differ only in that the call form is shadowable by a local binding named Array, which is what the rule guards against.

A changeset is included (@asyncapi/generator-react-sdk, patch).

What I have not done: I did not run the full monorepo build or test suite locally, so I am relying on CI for that rather than claiming a green run I did not observe. There are no existing unit tests covering these two utilities. The behavioural check above was run directly in Node v22.

Related issue(s)

Fixes #1915

AI assistance

Generated-by: Claude Code (Claude Opus, model claude-opus-5)

Disclosing per AI-POLICY.md. I read the policy after opening this PR and am editing the description to add the required line — the original description disclosed the AI assistance in prose but not in the machine-checkable form the policy asks for, which is my mistake, not the check's.

On the accountability point the policy makes ("AI tools are instruments; humans are the only authors"): this account is operated by an AI-assisted lab with the account owner's authorisation, and we take responsibility for every line here as if hand-written. The diff is two lines, the equivalence argument is verifiable in a Node REPL in seconds, and I can justify any part of it on request. If maintainers would rather not take AI-assisted contributions from a non-human-typed workflow regardless of disclosure, say so and I will close this myself without argument.

[changeset-bot]

🦋 Changeset detected

Latest commit: 05dcaac

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@asyncapi/generator-react-sdk	Patch
@asyncapi/generator	Patch
@asyncapi/generator-components	Patch

Not sure what this means? Click here to learn what changesets are.

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

[github-actions]

Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[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.

[coderabbitai]

📝 Walkthrough

Walkthrough

The React SDK now uses new Array() in indentation and newline string utilities. A patch changeset documents the update. Output behavior remains unchanged.

Changes

React SDK Array Constructors

Layer / File(s)	Summary
String utility constructor updates apps/react-sdk/src/utils/withIndendation.ts, apps/react-sdk/src/utils/withNewLines.ts, .changeset/sweet-donuts-repeat.md	The utilities now use explicit array constructors. The changeset records a patch release with no behavior change.

Estimated code review effort: 1 (Trivial) | ~3 minutes

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error)

Check name	Status	Explanation	Resolution
Title check	❌ Error	The title clearly describes the change and uses imperative mood, but it uses chore: although the patch changeset requires a release-triggering fix: prefix.	Change the title to fix(react-sdk): use new Array() constructor instead of Array().

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR replaces both Array() calls with new Array() as requested by issue #1915 and includes the related patch changeset.
Out of Scope Changes check	✅ Passed	The code and changeset changes are limited to the Array() replacements and the related React SDK patch release.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.}

[sonarqubecloud]

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

[batchu5]

@dkx955 Thank you for the PR, but as the changes are regarding a code style fix, there is no need for the changeset here; please remove it!

[Adi-204]

@dkx955 if you are still working on it please remove changeset we don't need to release it as it is just a code refactoring.