Proper pnpm support
I keep getting
in any situation where I use
which the docs use in multiple examples. A quick search reveals that the suggested solution is adding
however this does not resolve the issue.
If the issue is indeed from pnpm's side, couldn't a maintainer of sapphire open an issue in
pnpm's git repo about this since it's a pretty big thing? It seems a bit ignorant to tell the user to "switch to yarn" if they use pnpm. pnpm is a pretty popular choice, with over 3 million weekly downloads.
Normally I would open an issue on pnpm's repo. However, I don't really have deep enough technical knowledge as to what exactly is happening to open a good bug report.2 Replies
Quite frankly it's not our problem that pnpm forces uses to use their variant of PnP which is incompatible with big chunks of the NodeJS ecosystem. That's on them and their users to resolve. Previously hoisting worked just fine so I have no idea why it doesnt for you now. Maybe PnP should consider providing a standard TypeScript patch just like Yarn does but that's not for us to suggest to them.
I also think we support Yarn v3's PnP mode but that also needs hoisting and unplugging, it just be that way when you insist on using any form of PnP
That error is similar to one I often get when there are version conflicts, in which case I do what is suggested and use a type annotation. In the error it looks like @sapphire/result in the conflict (and I think
Option or one of its types is used as the return type for parse). Basically, just import that type yourself and manually annotate the return type of the function