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
Decide a ReferenceType's package name by looking for a package.json file #2017
Conversation
Looking at https://pnpm.io/symlinked-node-modules-structure... would an alternative, much less IO expensive, fix be to switch the |
That was my first attempt at a fix, which solves the problem of linking into the symlink farm, but not cross project links which won't have |
I've implemented the above, how does this look? |
I missed the cross project links mention in your original post - I'm probably missing something... not familiar with pnpm, but why would those not have node_modules? Are they not actually normal dependencies? |
In pnpm monorepo setups, you can list a package as a dependency of another package inside the monorepo workspace, and you'll get a symlink in node_modules to its actual location in the workspace, so assuming symlinks are being resolved you won't have |
Hmmm.... that's a thorny problem then. The test failures are real failures because the patch is inappropriately setting the |
... I might need to change the definition of |
Yeah, I'm convinced |
The current mechanism by which a
ReferenceType
figures out which package the type came from is by parsing the path and taking the first path element followingnode_modules
. This breaks when using pnpm which builds a symlink tree into a.pnpm
folder insidenode_modules
, so everyReferenceType
comes out.pnpm
. It also breaks if you're linking into a different project inside a monorepo, where there's nonode_modules
on the source path.The most immediate consequence of this is that plugins which resolve external links such as
typedoc-plugin-mdn-links
silently fail to do anything when using pnpm.This patch walks up the directory tree looking for a
package.json
file and grabbing the package name from itsname
key rather than trying to guess it from the file path, which solves the issues mentioned above.