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

Fix aws-monorepo example script types and core index export #524

Closed
wants to merge 1 commit into from

Conversation

rmarscher
Copy link

I started building yesterday off the latest aws-monorepo example and noticed the scripts folder sst-env.d.ts was still pointing to the old type file.

I also noticed I couldn't import from a packages/core/src/index.ts file without adding an entry to the exports in package.json.

Thanks!

@rmarscher
Copy link
Author

I'm finding a related issue with this workspace / tsconfig / package.json exports configuration:

If I create packages/core/src/utils.ts and then have an import from '@aws-monorepo/core/utils'. It's fine in my vscode type checker but when running with sst dev, the bundler says it can't find that module.

If I move it to packages/core/src/utils/index.ts, it works. If I find a fix before this PR closes, I'll update.

@rmarscher
Copy link
Author

  "exports": {
    ".": "./src/index.ts",
    "./*": [
      "./src/*.ts"
    ]
  }

works fairly well. You have to import @aws-monorepo/core/example/index or move example/index.ts to example.ts.

Still searching for a solution that supports all use cases. Understand this isn't really an SST Ion issue - although maybe there is something happening in the esbuild config that causes the module resolution to be different.

@jayair
Copy link
Contributor

jayair commented Jun 8, 2024

Yeah let me know if you find something for the index export issue.

@rmarscher
Copy link
Author

I have tried to find documentation on the array option for subpath exports in the esbuild and node.js docs but didn't see a solution. It seems like there's a general push towards using full import paths with extensions rather than rely on index resolution or automatic file extensions. In my personal project, I've been using the config from my comment and that works well for me.

I can set it to

  "exports": {
    ".": "./src/index.ts",
    "./*": [
      "./src/*.ts",
      "./src/*/index.ts"
    ]
  }

and it will continue to work for any non-index subpath entries but still won't work for @aws-monorepo/core/example. The first array entry ("./src/*.ts") seems to always be used without falling back to the second entry ("./src/*/index.ts").

Feel free to close this PR and handle it all another way. Thanks!

@rmarscher
Copy link
Author

Ah... here - evanw/esbuild#3536 and evanw/esbuild#2974

@rmarscher
Copy link
Author

I'm going to go ahead and close this. There's a disconnect between the way Typescript handles the exports field and the way esbuild handles it.

@rmarscher rmarscher closed this Jun 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants