feat: add batch transaction exports to public API

[nabe3m]

High Level Overview of Change

Add Batch transaction types and utilities to public API exports

• Export Batch, BatchFlags, BatchFlagsInterface, BatchInnerTransaction, and BatchSigner from transactions index
• Export GlobalFlags from common transaction types for use in batch inner transactions
• Include batchSigner utilities (signMultiBatch, combineBatchSigners) in main package exports
• Enable external packages to properly implement batch transaction functionality with full TypeScript support

Context of Change

This change addresses the need for external packages and applications to access batch transaction types, global transaction flags, and signing utilities that were previously internal to the library. Currently, developers trying to implement batch transaction handling must either:

1. Access these types through deep imports (not recommended)
2. Redefine the types themselves (error-prone)
3. Work without proper TypeScript support (unsafe)

By exposing these types and utilities through the public API, we enable:

• Proper TypeScript intellisense and type checking for batch transactions
• Access to GlobalFlags enum for setting flags on batch inner transactions (e.g., GlobalFlags.tfInnerBatchTxn)
• Access to official signing utilities for multi-account batch transactions
• Better developer experience when building applications that use batch functionality
• Consistency with other transaction types that are already exported

This architecture was chosen because:

• It follows the existing pattern of exporting all transaction types and their related interfaces
• GlobalFlags is essential for proper batch inner transaction construction
• It maintains backward compatibility while extending the public API
• It provides a clean, documented interface for batch transaction handling

Type of Change

• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that only restructures code)
• Tests (You added tests for code that already exists, or your new feature included in this PR)
• Documentation Updates
• Release

Did you update HISTORY.md?

• Yes
• No, this change does not impact library users (it's purely additive - no existing functionality changes)

Test Plan

Existing Tests:

• All existing batch transaction tests continue to pass
• Integration tests for signMultiBatch and combineBatchSigners verify functionality
• Unit tests for validateBatch ensure type safety

New Test Coverage:

• Verified that exported types can be imported from main package
• Confirmed TypeScript compilation succeeds with new exports
• Tested that applications can use the exported utilities without deep imports
• Verified GlobalFlags enum values are accessible for batch inner transaction flags

Manual Testing:

// Before: Required deep imports (not recommended)
import { BatchFlags } from 'xrpl/dist/npm/src/models/transactions/batch'
import { GlobalFlags } from 'xrpl/dist/npm/src/models/transactions/common'
import { signMultiBatch } from 'xrpl/dist/npm/src/Wallet/batchSigner'

// After: Clean public API imports
import { BatchFlags, GlobalFlags, signMultiBatch, combineBatchSigners } from 'xrpl'

// Usage example with GlobalFlags
const innerTx: BatchInnerTransaction = {
  TransactionType: "Payment",
  Account: wallet.classicAddress,
  Destination: destinationAddress,
  Amount: xrpToDrops("1"),
  Flags: GlobalFlags.tfInnerBatchTxn  // Now accessible from main export
}

Verification Steps:

1. Run npm test to ensure all existing tests pass
2. Verify TypeScript compilation: npm run build
3. Test import statements in sample application
4. Confirm GlobalFlags.tfInnerBatchTxn is accessible for batch inner transactions
5. Confirm no breaking changes to existing API surface

[coderabbitai]

Walkthrough

Adds new public re-exports: exposes Wallet/batchSigner from the package entry, expands transaction model re-exports to include Batch- and Global-related symbols, and updates HISTORY.md with an Unreleased "Added" note. No other code or behavior changes.

Changes

Cohort / File(s)	Summary
Package entry re-exports packages/xrpl/src/index.ts	Added export * from './Wallet/batchSigner' to expose batch signer APIs from the package root.
Transaction model re-exports packages/xrpl/src/models/transactions/index.ts	Expanded re-exports: from ./common added GlobalFlags, GlobalFlagsInterface; from ./batch added BatchFlags, BatchFlagsInterface, BatchInnerTransaction, BatchSigner.
Changelog packages/xrpl/HISTORY.md	Added an "Unreleased" → "Added" entry noting export of Batch transaction types and utilities (XLS-56).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

I’m a rabbit with a tiny quill,
I hop and add an export thrill.
Flags and signers join the feast,
From root to models — now released.
Thump, thump — ship it with a squeak! 🐇✨

Tip

🔌 Remote MCP (Model Context Protocol) integration is now available!

Pro plan users can now connect to remote MCP servers from the Integrations page. Connect with popular remote MCPs such as Notion and Linear to add more context to your reviews and chats.

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 854f585 and 554ddda.

📒 Files selected for processing (1)

• packages/xrpl/HISTORY.md (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• packages/xrpl/HISTORY.md

✨ Finishing Touches

🧪 Generate unit tests

• 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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore or @coderabbit ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

packages/xrpl/src/index.ts (1)

20-20: Prefer named re-exports to avoid leaking internals and to keep a stable public surface

Using a star export from './Wallet/batchSigner' may unintentionally re-export future helpers/types added to that module. Consider explicitly re-exporting only the intended public utilities.

Apply this diff:

-export * from './Wallet/batchSigner'
+export { combineBatchSigners, signMultiBatch } from './Wallet/batchSigner'

packages/xrpl/src/models/transactions/index.ts (1)

42-48: Consider adding minimal API smoke tests for the new exports

To guard against regressions in future refactors of barrels, add a test that imports these from the public entry and asserts their presence/types. Keeps the contract visible.

I can draft a lightweight test that imports from packages/xrpl/src (or the built package) and asserts Batch, BatchFlags, BatchInnerTransaction, and the wallet signMultiBatch/combineBatchSigners are available. Want me to add it?

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 5c816e4 and bfbcfc1.

📒 Files selected for processing (2)

• packages/xrpl/src/index.ts (1 hunks)
• packages/xrpl/src/models/transactions/index.ts (2 hunks)

🔇 Additional comments (3)

packages/xrpl/src/index.ts (1)

20-20: Sanity-check complete: no BatchSigner name collisions

• Inspected packages/xrpl/src/Wallet/batchSigner.ts exports via ripgrep: only signMultiBatch and combineBatchSigners are exported.
• No BatchSigner (type or value) is exported from that module, so it cannot collide with the BatchSigner type re-exported by models/transactions.

packages/xrpl/src/models/transactions/index.ts (2)

1-7: No Action Required: Symbol Kinds Verified

Both GlobalFlags and GlobalFlagsInterface are declared with the correct symbol kinds—GlobalFlags as an enum (value + type) and GlobalFlagsInterface as an interface (type only)—so they’ll behave correctly under verbatimModuleSyntax. All good here.

---

42-48: BatchSigner naming overlap check
The initial rg search in packages/xrpl/src for runtime exports of BatchSigner returned no matches, indicating no obvious class, const, function, or enum named BatchSigner is being exported elsewhere. However, absence of output isn’t definitive proof for default exports or more obscure patterns.

Please manually confirm in packages/xrpl/src/Wallet/batchSigner.ts that:

• It does not default-export a runtime symbol called BatchSigner.
• Any exported values (functions, constants, classes) use a different name or are type-only.

Once verified, there should be no naming conflict at the top-level barrel exports.

[mvadari]

Please update HISTORY.md

[nabe3m]

@mvadari Added. Please review.

[LJ-XRPL]

Thanks for your contribution @nabe3m - greatly appreciated!

[nabe3m]

@LJ-XRPL Thanks so much for your comment! I’ll do my best to keep contributing, even in small ways.

[tequdev]

LGTM