The library doesn't work on Deno.

[aslakhellesoy]

Describe the bug

It was fixed in #997, but as I've pointed out in #997 (comment), it doesn't work anymore. Maybe it's a regression.

To Reproduce

See stripe-samples/stripe-node-deno-samples#1 for a description on how to reproduce.

Expected behavior

No TypeScript errors.

Code snippets

No response

OS

macOS

Node version

Deno 1.21.3

Library version

Latest

API version

2020-08-27

Additional context

Deno compatibility should be verified in CI, to prevent regressions.

[ramya-stripe]

Thanks for reporting @aslakhellesoy
@kamil-stripe Can you please take a look?

[riderx]

i was able to make it work with some hack, since 3 weeks that stopped to work in production.
So i had to code with the REST API...
I still can't make the parsing event webhook work without the lib, for now, i cannot validate the payload that bad

[fredguest]

Hitting this bug too.

[riderx]

@fredguest if you need all my hack are available there:
https://github.com/Cap-go/capgo/tree/main/supabase/functions/_utils
i even found a way to parse the web hook by reverse engineering they code.
for api call check stripe file, and for event stripe_event

[fredguest]

@riderx thanks for that! 👍

[ItsWendell]

I would love to propose better support for Web-interoperable Runtimes like Cloudflare Workers and Deno. After a lot of hassle, I got this library working on Cloudflare Workers, but that required adding a lot of polyfills for Node APIs, which added 500kb+- to my bundle size.

The Node APIs in question I get issues for are: crypto, http, https, events. Some build systems allow you to build for multiple runtimes like Preconstruct recently added functionality for this..

I've used esbuild here to bundle this, not the native build tool in Wrangler or Webpack. The example in the stripe-examples also uses webpack to include polyfills, I personally think that using Polyfills is more of a workaround, than an actual solution.

[fredguest]

@ItsWendell in this video https://www.youtube.com/watch?v=epCHqHEdz8I they say they've done a bunch of refactoring specifically to support Deno and Cloudflare, which is encouraging, but clearly there's more work to be done.

[fredguest]

@ramya-stripe do you know if anyone has attempted to diagnose the issue recently? It sounds like it was working on Deno at one point, so it may be a quick fix to get it working again.

[ramya-stripe]

Hey everyone,

Unfortunately, we were not able to look into this recently, but will start definitely by the end of the week and try to diagnose the issue. Thanks for your patience here.

[dcr-stripe]

Sorry for the delay in responding here.

I was able to reproduce these failures in 1.21.3 and 1.21.1 (versions reported in the initial report) but when I upgrade to Deno 1.22.0 this resolves the issues. The produced errors are also type errors which are coming from the Deno internals rather than Stripe.

@fredguest , @aslakhellesoy : Could you confirm your Deno versions and whether it still happens when you upgrade?

---

@ItsWendell : Agreed going the web-interoperable runtime route would be ideal. For Cloudflare Workers, we actually explicitly removed the http/https packages as a no-op in our webpack config (https://github.com/stripe-samples/stripe-node-cloudflare-worker-template/blob/main/webpack.config.js#L17-L18) and you could feasibly do the same for crypto. This would result in a much smaller bundle. Then you would just need to initialize your Stripe client similar to the Deno initializer:

const stripe = Stripe(<API_KEY>, {
  // This is needed to use the Fetch API rather than relying on the Node http
  // package.
  httpClient: Stripe.createFetchHttpClient(),
});

If handling Webhooks:

// This is needed in order to use the Web Crypto API instead of Node.
const cryptoProvider = Stripe.createSubtleCryptoProvider();

receivedEvent = await stripe.webhooks.constructEventAsync(
  body,
  signature,
  <SIGNING SECRET>,
  undefined,
  cryptoProvider
);

You can see how this is configured in https://github.com/stripe-samples/stripe-node-deno-samples/tree/main/webhook-signing.

[fredguest]

@dcr-stripe thanks for looking into this. The bug I’m hitting may not actually be the same bug referred to in this issue, because I’m using Deno through Supabase edge functions (https://deno.com/blog/supabase-functions-on-deno-deploy) so the bug may be on the Supabase side.

I created an issue on the Supabase repo supabase/supabase#7878 before I found this issue on the Stripe repo, but I don’t actually have visibility into what Deno version Supabase is using while managing Deno installations.

I’ll reference this issue on the Supabase issue and see if I can get more information about the Deno version being used.

[ItsWendell]

Sorry for the delay in responding here.

I was able to reproduce these failures in 1.21.3 and 1.21.1 (versions reported in the initial report) but when I upgrade to Deno 1.22.0 this resolves the issues. The produced errors are also type errors which are coming from the Deno internals rather than Stripe.

@fredguest , @aslakhellesoy : Could you confirm your Deno versions and whether it still happens when you upgrade?

---

@ItsWendell : Agreed going the web-interoperable runtime route would be ideal. For Cloudflare Workers, we actually explicitly removed the http/https packages as a no-op in our webpack config (https://github.com/stripe-samples/stripe-node-cloudflare-worker-template/blob/main/webpack.config.js#L17-L18) and you could feasibly do the same for crypto. This would result in a much smaller bundle. Then you would just need to initialize your Stripe client similar to the Deno initializer:

const stripe = Stripe(<API_KEY>, {
  // This is needed to use the Fetch API rather than relying on the Node http
  // package.
  httpClient: Stripe.createFetchHttpClient(),
});

If handling Webhooks:

// This is needed in order to use the Web Crypto API instead of Node.
const cryptoProvider = Stripe.createSubtleCryptoProvider();

receivedEvent = await stripe.webhooks.constructEventAsync(
  body,
  signature,
  <SIGNING SECRET>,
  undefined,
  cryptoProvider
);

You can see how this is configured in https://github.com/stripe-samples/stripe-node-deno-samples/tree/main/webhook-signing.

Thanks for the fast response and looking into this! In the ideal world, this would be plug and play. We could have a "browser" / "worker" compatible export / build / bundle of stripe-node where custom webpack configuration for the consumer is not needed. This could be possible within the same NPM package.

I primarily use esbuild, where no-ops / polyfills are not as straight forward. I'll look into some examples of node packages that do this well and share them here later!

[fredguest]

@dcr-stripe just to keep you posted, Stripe is working again in Supabase.

The Supabase team identified a bug in Deno denoland/deno#15368 and released an update to the Supabase CLI that uses an older version of Deno supabase/cli#323 while they work with the Deno team to get the current version of Deno sorted.

[dcr-stripe]

Going to close this out with the proposed fix from #1428 (comment), which is to use Deno 1.22.0.

Please re-open if you're still experiencing issues with this.

Thanks!

[bombillazo]

Hey, we cant use npm: specifiers, so we are trying to import the stripe package from a CDN but our local code is not finding the types for the Stripe package.

[anniel-stripe]

Hi @bombillazo ! Unfortunately, this is a known issue related to #1636 as we currently define our types in an ambient module, which doesn't play well with use cases like Deno where the stripe package is imported via a URL or alias. You may find this answer helpful - it suggests using an import map as a workaround.

If that solution doesn't work for you, please open a new issue so we can keep better track of it!