-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for tree-shaking #1693
Comments
Thanks for the feature request, this is something we're actively working on! We're in the process of updating stripe-node to export an ESM package entrypoint, which will allow us to support tree-shaking. We believe there's more refactoring that has to be done past this effort for the package structure to be tree-shakeable, though. I'll keep this issue updated as we work on adding the ESM entrypoint, and when we start refactoring the package for better tree shaking. |
@anniel-stripe I am glad to read this, I can't wait for an ESM version of Stripe. Currently, Stripe is exported under a global namespace in TypeScript without any other export. This makes mocking the Stripe library very difficult for unit testing and we have to jump through many hoops and use unsafe practices to make unit tests work properly. It would be highly appreciated if you could stop using namespaces in the future as namespaces do not translate into anything JavaScript can understand. Ideally, simply export native modules without using the |
Hi, sorry for the late update here! An ESM entrypoint was added in stripe-node v11.15.0. In that entrypoint, we still use the
Could you elaborate how the global namespace we export in our types contributes to making Stripe hard to mock @SmashingQuasar ? If I understand correctly, the type definition shouldn't have runtime implications. Also, if you can share, it would be useful to see an example of the expected syntax vs. workarounds you have to employ in your unit tests. We do hope to stop using TypeScript namespaces in the future, likely as part of the effort to move away from defining our types in an ambient module. |
Sure, my initial post may have been unclear. Within the Now, when you want to mock the Because of how this has all been built and exported, TypeScript will gladly accept the following code: import { default as Stripe } from 'stripe';
const exampleCustomersResourceStub: { retrieve: SinonStub } = {
retrieve: stub(Stripe.Stripe.CustomersResource.prototype, 'retrieve')
}; However, this will obviously not work at runtime, because Now regarding exporting a class that has the same name as the namespace it causes two problems. I hope this clarifies my original post and gives more insight on TypeScript namespaces. This is a subjective post obviously, but as a rule of thumb, anything that has no Javascript reality should be exported as One last observation: I've noticed that you have many |
Thanks for the detailed explanation! This is very helpful to consider moving forward. I see what you mean now and completely agree with you - the TypeScript definitions don't reflect the reality, which negatively impacts the developer experience in cases like this. You're right that our |
If you need help to migrate your codebase, to re-evaluate the applicative architecture of the library or to improve TypeScript usage, I would be glad to help. |
Is your feature request related to a problem? Please describe.
Stripe apps developers are looking for a tree-shakeable Stripe SDK to help reduce the size of their apps
stripe/stripe-apps#817
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: