Skip to content

Conversation

@Ansonhkg
Copy link
Collaborator

@Ansonhkg Ansonhkg commented Sep 5, 2025

WHAT

The ugly import("dist/...") paths happen because the return/param types are not imported/re-exported from the public entry points. When TS generates declarations without a named import in scope, it inlines a path to the implementation file in the built output.

image

What this breaks

The would affect user experience because when they call these function it will just return :any type. This wasn't affecting local development because I was using locally linked packages and it was able to resolve the types.

Affected methods

  • mintWithEoa
  • mintWithAuth
  • mintWithCustomAuth
  • getPKPPermissionsManager
  • getPaymentManager
  • viewPKPPermissions

Solution

Map each offending signature to the external types it needs, expose them via package entry point and import them inside createLitClient

Copy link
Collaborator

@glitch003 glitch003 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good - just add types, pretty simple

…bug-some-methods-are-returning-any-2

Signed-off-by: Anson <[email protected]>
@Ansonhkg Ansonhkg merged commit f4f5926 into naga_add_hardcoded_keysets-3 Sep 16, 2025
2 of 3 checks passed
@Ansonhkg Ansonhkg deleted the feature/jss-82-naga-bug-some-methods-are-returning-any-2 branch September 16, 2025 17:12
@Ansonhkg Ansonhkg mentioned this pull request Sep 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🐞 Bug Fix Something isn't working v8 | Naga

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants