Skip to content

Conversation

@kayooliveira
Copy link
Contributor

This change aligns the SDK with modern JavaScript/TypeScript best practices, as default exports can cause confusion, especially when multiple exports exist in the same module.

Benefits:

  • Improves clarity and consistency when importing the SDK.
  • Reduces the chance of errors when integrating the SDK into other projects, as developers can now use import { AbacatePay } from 'abacatepay'.
  • Addresses an issue where users had difficulty with the default export, enhancing the integration experience.
  • Makes the API more modular and aligned with modern import/export patterns.

Note: The default export is still present but is marked as @deprecated and can be removed in future versions.

Closes #5

…xport): ♻️

### This change aligns the SDK with modern JavaScript/TypeScript best practices, as default exports can cause confusion, especially when multiple exports exist in the same module.

### Benefits: - Improves clarity and consistency when importing the SDK.
- Reduces the chance of errors when integrating the SDK into other projects, as developers can now use `import { AbacatePay } from 'abacatepay'`.
- Addresses an issue where users had difficulty with the default export, enhancing the integration experience.
- Makes the API more modular and aligned with modern import/export patterns.

### Note: The default export is still present but is marked as `@deprecated` and can be removed in future versions.

Closes AbacatePay#5
@ChristoPy
Copy link
Collaborator

How does it handles different environments like browser, typescript, EJS and CJS?

@kayooliveira
Copy link
Contributor Author

How does it handles different environments like browser, typescript, EJS and CJS?

Thanks for the question!

This PR aims to improve compatibility across environments by favoring named exports, which are better supported in both ESM and CJS when consumed through bundlers or TypeScript-aware tools.
Here's how this change helps across environments:

  • TypeScript (ESM): Named exports like import { AbacatePay } from 'abacatepay-nodejs-sdk' now offer proper IntelliSense and typings without requiring .default. This improves DX, especially in projects using "module": "ESNext" or "moduleResolution": "Bundler".

  • JavaScript (CommonJS): The default export is preserved for backward compatibility — e.g., const AbacatePay = require('abacatepay-nodejs-sdk') still works.

  • Browser (via bundler): Tools like Webpack, Vite, and Rollup correctly handle named exports and tree-shaking when consuming ESM modules. Named exports help with more efficient bundling here.

  • Pure JS or mixed EJS/CJS environments: If using import AbacatePay from 'abacatepay-nodejs-sdk' fails due to ESM/CJS interop quirks, the developer can fall back to const { AbacatePay } = require(...), which will now be valid due to the named export addition.

This update doesn’t break compatibility — it just adds more flexibility and improves developer experience in ESM and TypeScript setups. If the maintainers approve, we can mark the default export as deprecated in docs and fully transition in the next major release.

@ChristoPy
Copy link
Collaborator

Love the in depth details, will merge it very soon

@ChristoPy
Copy link
Collaborator

Oh, could you run the npm run lint command and sync with the main branch? We are currently in version 1.2.1 and not 1.1.0

@kayooliveira kayooliveira force-pushed the refactor/update-sdk-imports-to-named-imports branch from 60514af to bb263d4 Compare April 22, 2025 19:02
@kayooliveira
Copy link
Contributor Author

Oh, could you run the npm run lint command and sync with the main branch? We are currently in version 1.2.1 and not 1.1.0

Sure, done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Needing to call AbacatePay.default and not AbacatePay when using JS

2 participants