isaachinman Github contribution chart
isaachinman Github Stats
isaachinman Most Used Languages

Activity

04 Oct 2022

Issue Comment

Isaachinman

TypeScript types are invalid when expanding responses

Describe the bug

When expanding responses as per the documentation here, the return types for various Stripe methods are not updated to accurately reflect the modified responses.

To Reproduce

const stripeCustomer = await stripe.customers.retrieve(
  stripeCustomerId,
  {
    expand: ['subscriptions'],
  },
) 

Expected behavior

The returned data does indeed contain a nested subscriptions object:

"subscriptions": {
  "object": "list",
  "data": [...]
} 

However, the TypeScript types do not declare this at all.

Code snippets

No response

OS

macOS

Node version

Node v16.4.2

Library version

stripe-node v10.8.0

API version

2022-08-01

Additional context

No response

Forked On 04 Oct 2022 at 04:31:43

Isaachinman

@guanacone That's a general TS question, and unrelated to this SDK.

Commented On 04 Oct 2022 at 04:31:43
Issue Comment

Isaachinman

TypeScript types are invalid when expanding responses

Describe the bug

When expanding responses as per the documentation here, the return types for various Stripe methods are not updated to accurately reflect the modified responses.

To Reproduce

const stripeCustomer = await stripe.customers.retrieve(
  stripeCustomerId,
  {
    expand: ['subscriptions'],
  },
) 

Expected behavior

The returned data does indeed contain a nested subscriptions object:

"subscriptions": {
  "object": "list",
  "data": [...]
} 

However, the TypeScript types do not declare this at all.

Code snippets

No response

OS

macOS

Node version

Node v16.4.2

Library version

stripe-node v10.8.0

API version

2022-08-01

Additional context

No response

Forked On 20 Sep 2022 at 05:02:08

Isaachinman

@kamil-stripe Great, let me know if you need any advice/pointers. There are far more complex TypeScript projects out there than CRUD SDKs, so this should absolutely be possible.

And, thanks for clarifying about the DeletedCustomer union return type – not sure how I missed that.

For anyone reading this in the future, you can perform type-safe checks like this:

const customer = await stripeClient.customers.retrieve('stripeId')

if ('deleted' in customer) {
  // Customer is deleted
} else {
  // Properties can be accessed safely
  console.log(customer.created)
} 

Commented On 20 Sep 2022 at 05:02:08
Issue Comment

Isaachinman

TypeScript types are invalid when expanding responses

Describe the bug

When expanding responses as per the documentation here, the return types for various Stripe methods are not updated to accurately reflect the modified responses.

To Reproduce

const stripeCustomer = await stripe.customers.retrieve(
  stripeCustomerId,
  {
    expand: ['subscriptions'],
  },
) 

Expected behavior

The returned data does indeed contain a nested subscriptions object:

"subscriptions": {
  "object": "list",
  "data": [...]
} 

However, the TypeScript types do not declare this at all.

Code snippets

No response

OS

macOS

Node version

Node v16.4.2

Library version

stripe-node v10.8.0

API version

2022-08-01

Additional context

No response

Forked On 20 Sep 2022 at 06:49:18

Isaachinman

@kamil-stripe

The first issue will require some TypeScript trickery, but is possible. Unfortunately, in this case, an array of strings/enum values is probably the worst data structure to work with. You will likely need to instantiate a distinct type for each permutation of the expand array, as per this StackOverflow answer.

While implementing conditional types is necessary for type correctness, and should be implemented here as Stripe is a paid-product, I think the first step is to return the existing types in the first place, which leads into...

The second issue: I already provided the repro, based on the customers.retrieve method. You then wrote a snippet with the subscriptions.retrieve method – not sure why. Here's a codesandbox link.

Commented On 20 Sep 2022 at 06:49:18
Issue Comment

Isaachinman

TypeScript types are invalid when expanding responses

Describe the bug

When expanding responses as per the documentation here, the return types for various Stripe methods are not updated to accurately reflect the modified responses.

To Reproduce

const stripeCustomer = await stripe.customers.retrieve(
  stripeCustomerId,
  {
    expand: ['subscriptions'],
  },
) 

Expected behavior

The returned data does indeed contain a nested subscriptions object:

"subscriptions": {
  "object": "list",
  "data": [...]
} 

However, the TypeScript types do not declare this at all.

Code snippets

No response

OS

macOS

Node version

Node v16.4.2

Library version

stripe-node v10.8.0

API version

2022-08-01

Additional context

No response

Forked On 19 Sep 2022 at 07:33:32

Isaachinman

Hey @kamil-stripe, thanks for taking the time to respond.

Although the typing generally seems good for stripe-node, there appears to be significant issues with the subscriptions.list method, and possibly others.

Yes, the subscriptions property should be non-nullable when the expand array contains "subscriptions" – this should be easily achievable with generics.

However, I think there are more basic problems with the typing of this method:

const customer = await stripeClient.customers.retrieve('stripeId')

// Property 'created' does not exist on type 'Response<Customer | DeletedCustomer>'
console.log(customer.created) 

Commented On 19 Sep 2022 at 07:33:32
Issue Comment

Isaachinman

Manifest missing originalFullName in EAS Build Development Client

Summary

Manifest is missing originalFullName and currentFullName (and id) when using custom EAS Build Development client.

Managed or bare workflow? If you have made manual changes inside of the ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Android, iOS

Package versions

Only native and expo packages listed:

{
  "dependencies": {
    "expo": "^42.0.0",
    "expo-application": "~3.2.0",
    "expo-asset": "~8.3.2",
    "expo-auth-session": "~3.3.1",
    "expo-camera": "~11.2.1",
    "expo-constants": "~11.0.1",
    "expo-dev-client": "^0.4.3",
    "expo-device": "~3.3.0",
    "expo-image-picker": "~10.2.2",
    "expo-linear-gradient": "~9.2.0",
    "expo-linking": "~2.3.1",
    "expo-localization": "~10.2.0",
    "expo-notifications": "~0.12.2",
    "expo-random": "~11.2.0",
    "expo-secure-store": "~10.2.0",
    "expo-splash-screen": "~0.11.2",
    "expo-standard-web-crypto": "^1.0.2",
    "expo-status-bar": "~1.0.4",
    "expo-updates": "~0.8.0",
    "react": "16.13.1",
    "react-dom": "16.13.1",
    "react-native": "https://github.com/expo/react-native/archive/sdk-42.0.0.tar.gz",
    "react-native-gesture-handler": "~1.10.2",
    "react-native-reanimated": "~2.2.0",
    "react-native-safe-area-context": "3.2.0",
    "react-native-screens": "~3.4.0",
    "react-native-svg": "12.1.1",
    "sentry-expo": "^4.0.0",
  }
} 

Environment

Expo CLI 4.7.2 environment info:
    System:
      OS: Windows 10 10.0.19042
    Binaries:
      Node: 12.18.2 - ~\AppData\Local\Temp\yarn--1625626459530-0.2547605146813341\node.CMD
      Yarn: 1.22.10 - ~\AppData\Local\Temp\yarn--1625626459530-0.2547605146813341\yarn.CMD
      npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
    npmPackages:
      expo: ^42.0.0 => 42.0.0
      react: 16.13.1 => 16.13.1
      react-dom: 16.13.1 => 16.13.1
      react-native: https://github.com/expo/react-native/archive/sdk-42.0.0.tar.gz => 0.63.2
      react-native-web: ~0.13.12 => 0.13.18
    Expo Workflow: managed 

Reproducible demo or steps to reproduce from a blank project

  1. Create new expo 42 project
  2. Create a development client:
{
  "builds": {
    "android": {
      "debug": {
        "workflow": "managed",
        "buildType": "development-client",
        "releaseChannel": "test.42.0",
        "distribution": "internal"
      }
    }
  }
} 
  1. Try to create a redirect URI:
const useProxy = Platform.select({ web: false, default: true });
const redirectUri = AuthSession.makeRedirectUri({ useProxy }); 
  1. Start expo start --dev-client
  2. Install the dev client and connect
  3. It breaks

I went into node_modules\expo-auth-session\build\SessionUrlProvider.js and added console.log({ manifest }). I can see in the log that both originalFullName and currentFullName are missing.

expo config --type public 

This correctly shows originalFullName and currentFullName.

Workaround

import Constants from 'expo-constants';
Constants.manifest.originalFullName = '@org/project'; 

Right before AuthSession.makeRedirectUri

Stacktrace (if a crash is involved)

SessionUrlProvider.js

Error: Cannot use AuthSession proxy because the project ID is not defined. Please ensure you have the latest version of expo-constants installed and rebuild your native app. You can verify that currentFullName is defined by running expo config --type public and inspecting the output.

Forked On 05 Sep 2022 at 01:02:42

Isaachinman

@brentvatne

Is there any official documentation on this subject?

It seems the absence of manifest essentially breaks several/many expo packages when upgrading from 45 to 46-dev-client, and I cannot find any official guidance.

Is the workaround listed above seriously what's still needed, over a year later?

Commented On 05 Sep 2022 at 01:02:42
Issue Comment

Isaachinman

You cannot reload when expo-updates is not enabled

Summary

I'm using expo-updates's reloadAsync to reload app after changing language so the rtl/ltr direction can change. after upgrading to SDK 46 it's not working anymore and gives me this error [Unhandled promise rejection: Error: You cannot reload when expo-updates is not enabled.]

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Android, iOS

SDK Version (managed workflow only)

46

Environment

expo-env-info 1.0.5 environment info: System: OS: macOS 13.0 Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.6.0 - /opt/homebrew/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 8.13.2 - /opt/homebrew/bin/npm Managers: CocoaPods: 1.11.3 - /opt/homebrew/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: API Levels: 31, 32 Build Tools: 30.0.2, 30.0.3, 31.0.0 System Images: android-31 | Google APIs ARM 64 v8a, android-32 | Google Play ARM 64 v8a, android-Tiramisu | Google Play ARM 64 v8a IDEs: Android Studio: 2021.1 AI-211.7628.21.2111.8309675 Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild npmPackages: expo: ^46.0.0 => 46.0.2 react: 18.0.0 => 18.0.0 react-dom: 18.0.0 => 18.0.0 react-native: 0.69.3 => 0.69.3 react-native-web: ~0.18.7 => 0.18.7 Expo Workflow: managed

Reproducible demo

use reloadAsync from expo-updates to reload app

Forked On 09 Aug 2022 at 12:35:17

Isaachinman

@berkaygurbuz First, the issue only appears on iOS. Second, users posting in this issue (myself included) started seeing the error randomly, without bumping any major version.

Commented On 09 Aug 2022 at 12:35:17
Issue Comment

Isaachinman

You cannot reload when expo-updates is not enabled

Summary

I'm using expo-updates's reloadAsync to reload app after changing language so the rtl/ltr direction can change. after upgrading to SDK 46 it's not working anymore and gives me this error [Unhandled promise rejection: Error: You cannot reload when expo-updates is not enabled.]

Managed or bare workflow? If you have ios/ or android/ directories in your project, the answer is bare!

managed

What platform(s) does this occur on?

Android, iOS

SDK Version (managed workflow only)

46

Environment

expo-env-info 1.0.5 environment info: System: OS: macOS 13.0 Shell: 5.8.1 - /bin/zsh Binaries: Node: 18.6.0 - /opt/homebrew/bin/node Yarn: 1.22.19 - /opt/homebrew/bin/yarn npm: 8.13.2 - /opt/homebrew/bin/npm Managers: CocoaPods: 1.11.3 - /opt/homebrew/bin/pod SDKs: iOS SDK: Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5 Android SDK: API Levels: 31, 32 Build Tools: 30.0.2, 30.0.3, 31.0.0 System Images: android-31 | Google APIs ARM 64 v8a, android-32 | Google Play ARM 64 v8a, android-Tiramisu | Google Play ARM 64 v8a IDEs: Android Studio: 2021.1 AI-211.7628.21.2111.8309675 Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild npmPackages: expo: ^46.0.0 => 46.0.2 react: 18.0.0 => 18.0.0 react-dom: 18.0.0 => 18.0.0 react-native: 0.69.3 => 0.69.3 react-native-web: ~0.18.7 => 0.18.7 Expo Workflow: managed

Reproducible demo

use reloadAsync from expo-updates to reload app

Forked On 06 Aug 2022 at 12:54:00

Isaachinman

Also experiencing this issue in Expo 45. Most likely this must be a regression in Expo Go itself, not the core SDK?

Commented On 06 Aug 2022 at 12:54:00
Issue Comment

Isaachinman

Error middleware not properly invoked when using async functions

When using supertest to test an express app together with the example in the readme from https://github.com/davidbanham/express-async-errors, it seems supertest will not properly invoke the error handling middleware, and thus the test just times out rather than actually responding with the logic defined in the error handler.

This behaviour works when invoking the code via HTTP.

Forked On 04 Aug 2022 at 04:32:31

Isaachinman

Also facing this issue with Express v5, and am happy to work on a PR if someone can point me in the right direction.

Commented On 04 Aug 2022 at 04:32:31
Issue Comment

Isaachinman

Type error: '?' expected.

Versions

  • @prismicio/helpers: 2.3.2
  • node: v16.13.1
  • typescript: 4.5.4

Reproduction

I updated to 2.3.2 and when I run tsc I get this error:

./node_modules/@prismicio/helpers/dist/index.d.ts:399:2
Type error: '?' expected.

  397 |     embed_url: string;
  398 |     html: string | null;
> 399 | }) ? {
      |  ^
  400 |     [x: string]: never;
  401 | } | (Data & {
  402 |     embed_url: string; 

Steps to reproduce

  • npm i @prismicio/helpers@2.3.2
  • run tsc

What is expected?

The build compiles

What is actually happening?

Failed to compile

Workaround

Use v2.3.1

Forked On 01 Aug 2022 at 09:46:59

Isaachinman

Just got caught by this as well. @lihbr Just a heads up, the TypeScript project routinely introduces breaking changes on minor versions. Something to watch out for.

Commented On 01 Aug 2022 at 09:46:59
Issue Comment

Isaachinman

`router.replace` SecurityError: The operation is insecure. (Firefox 102.0.1 (64-bit))

Verify canary release

  • [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

➜ npx --no-install next info

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.5.0: Tue Apr 26 20:57:23 PDT 2022; root:xnu-8020.121.3~2/RELEASE_ARM64_T8110
    Binaries:
      Node: 16.16.0
      npm: 8.11.0
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.2.4-canary.0
      eslint-config-next: 12.2.1
      react: 18.2.0
      react-dom: 18.2.0 

What browser are you using? (if relevant)

Firefox 102.0.1 (64-bit)

How are you deploying your application? (if relevant)

npm run dev

Describe the Bug

When using the router.replace function, Firefox throws a runtime error: SecurityError: The operation is insecure.

Expected Behavior

Using router.replace should not throw a SecurityError.

Link to reproduction

https://github.com/hexcowboy/next-js-SecurityError

To Reproduce

  1. Clone the reproduction repo
  2. Run npm i
  3. Run npm run dev
  4. Open http://localhost:3000/ on Firefox 102.0.1 (64-bit)

Forked On 30 Jul 2022 at 05:43:14

Isaachinman

@hexcowboy I'm also seeing this in FF. Why did you close the issue?

Commented On 30 Jul 2022 at 05:43:14

Isaachinman

How to stop node-oauth2-jwt-bearer from polluting my output

I am using this package for an express app running on AWS Lambda which prints all output to CloudWatch:

import { auth } from 'express-oauth2-jwt-bearer';

export default auth({
  jwksUri: ...,
  issuer: ...,
  audience: ...,
}); 

The issue is that every time someone tries to access my endpoints with an expired token (or invalid, or without token), the package throws some errors such as this one: InvalidTokenError: "exp" claim timestamp check failed

Question: How do I catch those before they hit the console? I don't want them to reach CloudWatch at all.

I tried wrapping the code with try/catch but it doesn't stop the error from going to console:

const authFn = auth({...});

export default async (req, res, next) => {
  try {
    const result = await authFn(req, res, next);
  } catch(e) {
    // handle error
  }
}; 

Forked On 24 Jul 2022 at 04:00:14

Isaachinman

@rococtz @adamjmcgrath I've seen identical InvalidTokenError: "exp" claim timestamp check failed errors, despite my JWTs being set to a 30 day expiry (in the Auth0 dashboard).

For my user base, this means that expired tokens should almost never happen, yet I see these errors many times per day.

Any hints as to how these errors can be debugged? As @rococtz hints at, even reqs without a token end up spitting out "exp" claim timestamp check failed, so I have a feeling this error block is unintentionally catching many other errors.

Commented On 24 Jul 2022 at 04:00:14
Issue Comment

Isaachinman

Call for maintainer(s)

Hi all, it's been four years now since I released next-i18next@0.1.0, and I feel truly privileged to have contributed to the NextJs ecosystem, and hopefully helped save some other devs' precious time.

Due to other projects and a sheer lack of time, I'll now pass the torch. Hopefully we can find a committed and competent maintainer to continue active development, otherwise I will put the project into archival.

Alternatively, there are several other NextJs i18n packages which are popular these days, so another option would be to simply merge projects, or create an easy migration path for users. I do hope that eventually, NextJs as a framework will support i18n first-class.

Pinging some relevant names, but feedback from anyone is appreciated!

@adrai @kachkaev @aralroca @amannn

Forked On 07 Jul 2022 at 07:06:44

Isaachinman

Moving next-i18next under the i18next org sounds like a great solution. @jamuhl and @adrai are more than competent in handling all internationalisation issues, and hopefully the community can lend some support in regards to the trickier aspects of NextJs.

Perhaps in the end, this shift could lead to a great simplification of the code – let's see.

I'll speak to the i18next team privately to start the process.

Thanks everyone!

Commented On 07 Jul 2022 at 07:06:44