namespacing modules

Prologue

The current library contains exports for all possible resources supported by the Razorpay SDK. This is a tightly-coupled architecture and it should be noted that it adds a lot of weight to the process utilizing the resource.

Solution

The library should be namespaced based on the resources with one module being a wrapper around all of them.

For example, to use the payments resource:

const Payments = require( '@razorpay/payments' );
const apiObject = new Payments.extend( { ... } ); // or new Payments( { ... } );

Or to use the entire SDK:

const Razorpay = require( '@razorpay/sdk' );
const { Payments } = new Razorpay( { ... } );

Benefits

This will help the use decide exactly what they want to use and the test cases will be targeted specifically at the resource providing higher case testing as opposed to case coverage.

Meta Information

Implementation Time: 5 days
Implementation Complexity: Intermediate (or Easy)

Tags

suggestions, enhancements, documentation, testing, BREAKING CHANGE

Start by mapping the current library exports and resource entry points, then compare them with the proposed @razorpay/payments and @razorpay/sdk interfaces. Review the existing test coverage before deciding how resource-specific modules and the full SDK wrapper should be organized. Done means resources can be consumed independently or through the full SDK, with targeted tests and the breaking change documented.