[rush] PNPM v7 commitlint autoinstaller doesn't work

[Faithfinder]

Summary

Cannot upgrade our repo to pnpm v7. We're using commitlint, and autoinstaller breaks on v7

Repro steps

Repro here: https://github.com/Faithfinder/rush-pnpm7-commilint-repro

• Checkout main
• rush update to install git hooks
• Try to make a commit (empty is fine) with random letters, get error:

⧗   input: asdfasdf
✖   subject may not be empty [subject-empty]
✖   type may not be empty [type-empty]

✖   found 2 problems, 0 warnings

• Try to make a commit conforming to standard, ie test: commit, succeed
  • These steps are just to check that commitlint is set up correctly and working, all behaviour intended.
• Checkout pnpmv7 branch (or update pnpm to v7 in rush.json)
• Try to make the same conforming commit, get error:

dependencies:
+ @commitlint/cli 17.0.2
+ @commitlint/config-conventional 17.0.2

Progress: resolved 189, reused 189, downloaded 0, added 189, done
Auto install completed successfully

Error: Cannot find module "@commitlint/config-conventional" from "/home/misamoto/Source/OpenSource/rush-pnpm7-commilint-repro"

Details

Something changed with pnpm v7 module resolution that messes with autoinstallers :(

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/rush globally installed version?	5.74.0
rushVersion from rush.json?	5.74.0
useWorkspaces from rush.json?	true
Operating system?	WSL
Would you consider contributing a PR?	Eh... Wouldn't know where to start, a bit low level for me, but I can try with guidance
Node.js version (node -v)?	16.15.1

[iclanton]

This isn't an issue with Rush or PNPM, it's an issue with commitlint. Changing this line to cwd: __dirname and this line to cwd: cwd fixes the issue. commitlint uses an incorrect assumption about the way it was installed when performing module resolution that was exposed by changes to the installation topology in PNPM 7.

I'd recommend you raise an issue with commitlint. They should be able to fix this issue by either using a more conventional module resolution tool (like node's built-in require) or correctly passing module context between calls to their custom module resolver.