fix: copy built-in awaited type

[Newbie012]

It fixes a bug when trying to use the atom in conjunction with generics. Given the following code:

const useX = <$StageName extends string>(params: {
    atom: WritableAtom<$StageName, SetStateAction<$StageName>, void>;
    stages: $StageName[];
  }) => {
    const [currentStage, setCurrentStage] = useAtom(params.atom);
    const stageNames = Object.keys(params.stages) as $StageName[];
    const currentStageNumber = stageNames.indexOf(currentStage) + 1;
}

I get the following error:

Argument of type 'Awaited<$StageName>' is not assignable to parameter of type '$StageName'.
  'Awaited<$StageName>' is assignable to the constraint of type '$StageName', but '$StageName' could be instantiated with a different subtype of constraint 'string'.
    Type 'unknown' is not assignable to type '$StageName'.
      '$StageName' could be instantiated with an arbitrary type which could be unrelated to 'unknown'.ts(2345)

Using the built-in Awaited type fixes this issue.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
jotai	✅ Ready (Inspect)	Visit Preview	Jun 20, 2022 at 2:56PM (UTC)

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit a24684f:

Sandbox	Source
React	Configuration
React Typescript	Configuration
React Browserify	Configuration
React Snowpack	Configuration
Next.js	Configuration
Next.js with custom Babel config	Configuration
React with custom Babel config	Configuration

[dai-shi]

Thanks for reporting. I wasn't aware the issue with generics.
While your solution makes sense to fix the issue, it doesn't feel very ideal. We want to use the built-in one, right?
Would you be interested in contributing to https://github.com/sandersn/downlevel-dts ?

[Newbie012]

Hey @dai-shi, sorry it took a long time to respond.

I agree. We should probably use the built-in type and let downlevel-dts do the extra work.
In fact, I tried to do it here but it turns out to be tricky since it's recursive, and I wasn't able to find a similar implementation.
For now, I've opened an issue sandersn/downlevel-dts#78 hoping I'll get a lead so I can merge it.
Although, I was wondering why did you redeclare the type in each module instead of exporting it once?

[dai-shi]

Although, I was wondering why did you redeclare the type in each module instead of exporting it once?

It's not only about this type, but I try not to export private types (public types are defined in ./src/index.ts), because we will change private types without notice, which breaks if people accidentally using private types (if it's exported).

[Newbie012]

Interesting!
Anyway, not sure why I got so confused last night. I've opened a PR to downlevel-dts. Placing it here for a follow-up

sandersn/downlevel-dts#79

[Newbie012]

@dai-shi I haven't got a response for the PR I made on downlevel-dts. In short, I've stumbled across this issue which I believe would be a problem merging this PR.

For now, I believe we have two choices - keep the current state and open an a new bug issue, or merge it until further development. Honestly, I'm not happy with either of these options 🙁.

[dai-shi]

keep the current state and open an a new bug issue

Let's do this. Closing this PR for now.

For your case, I think module augmentation would work.
Check this workaround: https://tsplay.dev/mLqX2W