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

Path resolving issue in monorepo? #140

Open
Sliov opened this issue May 29, 2024 · 3 comments
Open

Path resolving issue in monorepo? #140

Sliov opened this issue May 29, 2024 · 3 comments

Comments

@Sliov
Copy link

Sliov commented May 29, 2024

I'm trying to resolve files in my monorepo but without luck, it seems to work fine tho on the existing mdxts site

Using:

  • Bun 1.1.10
  • Node.js 20.14.0
  • MacOS Sonoma 14.5

Here's the full repro: https://github.com/Sliov/mdxts-turbo-repro

Also, I noticed (when the files are resolved & colocated) that the extracted sourcePath is a bit weird, it includes a vscode path for some reason?

Screenshot 2024-05-29 at 8 27 35 PM

Oh, and as we can deconstruct exportedTypes from the component, would it be possible to pass it down to the ExportedTypes component as a value?

Sorry, maybe that's 3 issues in 1 😬

@souporserious
Copy link
Owner

This looks like it might be a bug in the logic for getEntrySourceFiles which determines what is publicly exported.

Also, I noticed (when the files are resolved & colocated) that the extracted sourcePath is a bit weird, it includes a vscode path for some reason?

That's the correct behavior for sourcePath 😄. Locally it points to the local source files on your machine and in production it will use the configured git source.

Oh, and as we can deconstruct exportedTypes from the component, would it be possible to pass it down to the ExportedTypes component as a value?

ExportedTypes is meant to be used outside of createSource so they are related in the data they grab for you, but are not meant to be used together. I have some ideas to clean this up though as I can understand it might be confusing. We're you hoping to use this for rendering the formatted types for a source?

@Sliov
Copy link
Author

Sliov commented May 30, 2024

This looks like it might be a bug in the logic for getEntrySourceFiles which determines what is publicly exported.

Thank you, I'll try to debug on my end with my limited knowledge see if I can find anything

That's the correct behavior for sourcePath 😄. Locally it points to the local source files on your machine and in production it will use the configured git source.

Ok makes sense, thank you 👍

ExportedTypes is meant to be used outside of createSource so they are related in the data they grab for you, but are not meant to be used together. I have some ideas to clean this up though as I can understand it might be confusing. We're you hoping to use this for rendering the formatted types for a source?

Sorry I forgot to add some context, I can see exportedTypes is present in the resolved component: https://github.com/Sliov/mdxts-turbo-repro/blob/main/apps/docs/src/app/components/%5Bslug%5D/page.tsx#L21C42-L21C55

I just thought it would more performant to pass the exportedTypes data to the <ExportedTypes /> component instead of having the component to lookup the source/value and parse it again?

@souporserious
Copy link
Owner

Sounds good, let me know if you have any questions! I'll take a look when I get a chance to see what's causing it to not return any results.

As for exported types, yeah there's definitely some performance savings to be had there and the whole type analysis in general. For now, I'd suggest just using the exportedTypes metadata on a data source item if you're using that to not overanalyze.

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

No branches or pull requests

2 participants