typedoc
typedoc copied to clipboard
TypeStrong
Decide a ReferenceType's package name by looking for a package.json file
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 following node_modules. This breaks when using pnpm which builds a symlink tree into a .pnpm folder inside node_modules, so every ReferenceType comes out .pnpm. It also breaks if you're linking into a different project inside a monorepo, where there's no node_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 its name key rather than trying to guess it from the file path, which solves the issues mentioned above.
Looking at https://pnpm.io/symlinked-node-modules-structure... would an alternative, much less IO expensive, fix be to switch the indexOf("node_modules") to lastIndexOf("node_modules")?
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 node_modules in their path at all. Looking at it again with performance in mind, it would be better to try lastIndexOf first, and look for a package.json only if that gives no result. It's probably worth caching the package.json lookups too.
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? package isn't meant to be set for references which aren't from a dependency.
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 node_modules in the dependency's path.
Hmmm.... that's a thorny problem then. The test failures are real failures because the patch is inappropriately setting the package property on all reference types. I'm going to try setting up a pnpm setup and see if there's a better way to do this...
... I might need to change the definition of ReferenceType.package, not happy about it, but... going to think about this some more.
Yeah, I'm convinced ReferenceType.package should (almost) always be set. This is a pretty major breaking change, so it's going to have to be a part of 0.24 though.