Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore ways to check package.json exports paths #2023

Open
sodic opened this issue May 8, 2024 · 0 comments
Open

Explore ways to check package.json exports paths #2023

sodic opened this issue May 8, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@sodic
Copy link
Contributor

sodic commented May 8, 2024

Not tagging this as a bug since it's not a userland bug.
It's a missing check in our development flow that can (and on several occasions did) result in userland bugs. I don't know what's the appropriate label for such things.

Steps to reproduce:

  1. Map an exports path in sdk/wasp/package.json to something that doesn't exist. For example:

    "./universal/types": "./dist/universal/somethingMadeUp.js",
    
  2. Witness all our checks system fail to detect the error.

Why it matters

  1. Building the SDK creates .d.ts files with unresolvable imports. I'm not sure why the build doesn't realize this - potentially because it doesn't use the exports field for resolving types.
  2. Users import the wasp package, and TypeScript silently resolves these unresolved imports to anys.
  3. Users have incorrect types. The anys propagate to the top. So, most of the times, the types aren't wrong, they're missing (that's why our todoApp build doesn't catch them).

Possible solutions

  • Ideal: Find a way to enforce correct paths in the package.json exports field.
  • Alternative: Find a way to e2e test our exposed types more robustly.
@sodic sodic added the enhancement New feature or request label May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant