[Bug?]: Incorrect import exported class

2hoyeong commented 2 years ago

Self-service

[ ] I'd be willing to implement a fix

Describe the bug

// "otplib": "^12.0.1"

import { authenticator } from 'otplib';

...
  generateOtpPath(user: string, secret: string): string {
    return authenticator.keyuri(user, this.serviceName, secret); // 👈  Property 'keyuri' does not exist on type 'Authenticator<AuthenticatorOptions<string>>'.ts(2339)
  }

  checkOtp(token: string, secret: string): boolean {
    if (authenticator.check(token, secret)) { // 👈  Property 'check' does not exist on type 'Authenticator<AuthenticatorOptions<string>>'.ts(2339)
      return true;
    }
    throw new ClientRequestException(ERROR_CODE.ERR_004004);
  }
...

otplib -> @otplib/preset-default -> import { Authenticator, AuthenticatorOptions, HOTP, HOTPOptions, TOTP, TOTPOptions } from '@otplib/core';

// @otplib/core/index.d.ts

export * from './utils';
export * from './hotp'; // module "/Users/hoyeong/Code/playground/nestjs_practice/.yarn/cache/@otplib-core-npm-12.0.1-4b9787d379-b3c34bc20b.zip/node_modules/@otplib/core/hotp"
export * from './totp'; // module "/Users/hoyeong/Code/playground/nestjs_practice/.yarn/cache/@otplib-core-npm-12.0.1-4b9787d379-b3c34bc20b.zip/node_modules/@otplib/core/hotp"
export * from './authenticator';

htop and totp incorrectly imports same file in same directory. So Authenticator types inheriting htop is inferred to the wrong type(class).

When using node_modules correctly working. (npm, yarn 1.22.11)

To reproduce

Here is a very simple repo that reproduces the issue https://github.com/2hoyeong/nestjs_practice/tree/yarn-test

Environment

System: OS: macOS 11.5.1 CPU: (8) x64 Apple M1 Binaries: Node: 12.22.1 - /private/var/folders/4c/56ntc07914g87k_ty3lstvz40000gn/T/xfs-49ee302c/node Yarn: 3.0.0 - /private/var/folders/4c/56ntc07914g87k_ty3lstvz40000gn/T/xfs-49ee302c/yarn npm: 6.14.12 - ~/.nvm/versions/node/v12.22.1/bin/npm

Additional context

No response

yarnbot commented 2 years ago

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

merceyz commented 2 years ago

I must have missed this one, sorry about that. Fixed in https://github.com/yarnpkg/berry/pull/3297, run the following commands to apply the fix

yarn set version berry && yarn

yarnpkg / berry