refactor: simplify lookupFile #12585
Conversation
|
|
| const filePath = path.join(envDir, file) | ||
| if (!tryStatSync(filePath)?.isFile()) return [] | ||
|
|
||
| return Object.entries(parse(fs.readFileSync(filePath))) |
There was a problem hiding this comment.
We were passing rootDir: envDir here, so only level would be checked by lookupFile but the call makes it seems env dirs are being looked up in the fs. Replaced it with a single tryStatSync
| function findNearestLockfile(dir: string) { | ||
| while (dir) { | ||
| for (const fileName of lockfileNames) { | ||
| const fullPath = path.join(dir, fileName) | ||
| if (tryStatSync(fullPath)?.isFile()) return fullPath | ||
| } | ||
| const parentDir = path.dirname(dir) | ||
| if (parentDir === dir) return | ||
|
|
||
| dir = parentDir | ||
| } | ||
| } |
There was a problem hiding this comment.
I think we can have a specialized version of the lookup here, this was the reason the second argument to lookupFile was an array in all other places.
There was a problem hiding this comment.
I think It'd still prefer the array version instead so we don't have two similar code 🤔 There shouldn't be a huge perf hit for the case where an array isn't needed too.
There was a problem hiding this comment.
done, the function isn't used much now anyways
| ) { | ||
| return lookupFile(parentDir, formats, options) | ||
| export function lookupFile(dir: string, fileName: string): string | undefined { | ||
| while (dir) { |
There was a problem hiding this comment.
Removed the recursion, this is the same scheme used by @bluwy in findNearestPackageData.
Description
After #12577 and #12576, there are only a few places where we are using
lookupFile. Its API got quite complex and I think it is hiding the caller intention in some places. This PR simplifies the function. We may remove it later on, once we remove the CJS SSR build, it only will have a single use case (that could be replaced by afindNearestPackageData)What is the purpose of this pull request?