Closed jtenner closed 5 years ago
Ah yes this is a special case and the default resolution doesn't understand. Unfortunately it sees the the package as @morp
and then tries the default location of assembly
. There is a solution that I see for this in the short term to get it to compile, but you'll lose you're typing info in your IDE.
The solution is to change the import to btree
and then via cli --path ./node_modules/@morp
, which then it will use to look for the btree
package in that directory. Unfortunately this means that the IDE will look into node_modules/btree
and it won't be found.
Thanks for testing this stuff out. The real solution is to use the fact that the import starts with an @
and do internally what you have to do manually.
It might be possible to use a triple slash directive to still access the types, but I think you'd have to output a types file for the package.
Let me know how the short term suggestion works and I'll add this to my list of fixes.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I'm using a lerna repo for my MUD engine. The
--lib
folder in question is located in:The package itself relies on is the
@morp/btree
package, located here:The dependencies for the primary
@morp/assembly
package are as follows:I checked the
./packages/assembly/node_modules/@morp/btree
folder to verify that lerna has properly bootstrapped the package.After hooking into the readfile function of the compiler I was able to gather a list of all the files it was trying to validate.
Often, it will skip over
@morp/btree
in favor of@morp/assembly/btree.ts
and the like. It doesn't think to treat@morp/btree
like a package folder and ends up failing to find a lib entry point.Edit: I probably have this all wrong. I'm just very frustrated and it looks like the package resolver doesn't know where to look.