Open drewbietron opened 1 year ago
'm able to reproduce this on my end. The client is not being typed. @dcr-stripe any idea what might be going on here?
Hey hey! 👋 Unfortunately @dcr-stripe isn't working at Stripe anymore so I've asked the SDK team for some insights about what the issue might be. Hopefully I'll get some answers and will get back to you!
Hey @thorwebdev and @drewbietron, this is happening because we use "ambient module declaration" in our types for stripe-node, which Deno doesn't know how to handle.
Luckily there's a workaround by using Deno's new npm module compatibility mode:
import Stripe from 'npm:stripe@11.1.0';
export const stripeClient = new Stripe(
Deno.env.get("STRIPE_SECRET_KEY") as string,
{
apiVersion: "2022-11-15",
httpClient: Stripe.createFetchHttpClient(),
}
);
// stripeClient is now an instance of Stripe
Also make sure you instantiate the Stripe
instance with new
.
thanks @paulasjes-stripe. Strange, I could have sworn that this used to work with esm.sh
import in the past.
Unfortunately Deno Deploy / Supabase does not yet support npm module compatibility 😞
I'm not sure if types have ever worked with esm.sh
. I tried importing the types directly with
/// <reference types="https://esm.sh/v99/stripe@11.1.0/es2022/types/index.d.ts" />
but index.d.ts
here only contains
/* fake(empty) types */
which is less than helpful.
Unfortunately I don't think types are going to work when importing from esm.sh
, at least not in the short run.
Thanks @thorwebdev and @paulasjes-stripe for looking into this everyone. I also tried just using local type files and importing them using // @deno-types=
but it oddly results in duplicate type declarations from it's esm.sh counterpart.
// @deno-types="../types/stripe/2022-11-15/index.d.ts" <-- copied type directory from stripe npm import here
import Stripe from "https://esm.sh/stripe@11.2.0?target=deno";
export const stripeClient = Stripe(Deno.env.get("STRIPE_SECRET_KEY"), {
apiVersion: "2022-11-15",
httpClient: Stripe.createFetchHttpClient(),
});
'Stripe' was also declared here.
export default Stripe;
at https://esm.sh/v99/stripe@11.1.0/types/2022-11-15/index.d.ts:284:18
For a type declaration file from esh that has no types, how does it have a duplicate type?
Do you think heading down this local type file is a viable path? Id be wiling to do whatever for now just to get types going in the Deno functions as its pretty hard to deal with otherwise.
Thanks!
Asked on Deno's Discord and found a workaround for now that should work while we consider switching away from ambient modules.
We can explicitly tell Deno to use the available types using an import map. Create a import_map.json
file with
{
"imports": {
"stripe": "https://esm.sh/stripe@11.1.0?target=deno"
}
}
Then add in your deno.json
(or create deno.json
and add this):
{
"importMap": "./import_map.json"
}
Now when importing "stripe"
you should see the types as expected:
You might need to restart Deno's language server to have it pick up the types.
Thanks @paulasjes-stripe!
The issue seems to persist.
Sadly @paulasjes-stripe `s solution also does not work for me :(
This worked for me:
import { Stripe } from "https://esm.sh/stripe@16.2.0/";
import type { Stripe as TStripe } from "https://esm.sh/v135/stripe@16.2.0/types/index.d.ts";
export const stripe: TStripe = new Stripe(
Deno.env.get("STRIPE_SECRET_API_KEY")!,
{ httpClient: Stripe.createFetchHttpClient() },
);
While importing the Stripe library, the types come back as
any.
. I've tried as many combinations of esh imports for the Stripe library as I can and am at a loss. Here is what my current Deno function looks like.Any help would be appreciated.