-
Notifications
You must be signed in to change notification settings - Fork 917
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bug where function discovery failed on projects using yarn workspaces. #5215
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
7c666f6
to
7de7f09
Compare
b7fd039
to
1822bac
Compare
Codecov ReportBase: 56.27% // Head: 56.28% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## dl-cf3-discover-test #5215 +/- ##
========================================================
+ Coverage 56.27% 56.28% +0.01%
========================================================
Files 309 309
Lines 20838 20828 -10
Branches 4227 4227
========================================================
- Hits 11726 11723 -3
+ Misses 8100 8093 -7
Partials 1012 1012
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
7de7f09
to
960f1b4
Compare
1822bac
to
a2b0f24
Compare
960f1b4
to
1d21dee
Compare
a2b0f24
to
43d41e6
Compare
1d21dee
to
ff2647b
Compare
43d41e6
to
591e866
Compare
ff2647b
to
7d28a88
Compare
591e866
to
deac733
Compare
7d28a88
to
dc1163b
Compare
deac733
to
163e2a3
Compare
dc1163b
to
51ddf7e
Compare
163e2a3
to
af6ff32
Compare
51ddf7e
to
95a4810
Compare
af6ff32
to
b9b8177
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
small q on the while loop but LGTM
export function findModuleVersion(name: string, resolvedPath: string): string | undefined { | ||
let searchPath = path.dirname(resolvedPath); | ||
// eslint-disable-next-line no-constant-condition | ||
while (true) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think search path will always terminate with /
, right? Why not use that as the condition instead of doing while (true)
?
95a4810
to
0bdee8d
Compare
b9b8177
to
a3690a8
Compare
0bdee8d
to
cce0388
Compare
a3690a8
to
250c1fe
Compare
Graphite Merge Job Current status: ✅ Merged This pull request was successfully merged as part of a stack. This comment was auto-generated by Graphite. Job Reference: Uhty8UE38l3MKEIRA9gp |
250c1fe
to
9106087
Compare
…orepo setups (#5391) Partially fixes #4952. #5215 made changes to the CLI to detect Functions SDK even in monorepo setups where Functions SDK is hoisted (i.e. Functions SDK dependency is declared in the parent directory but not in the sub-package directory). We should've made corresponding change in how the Functions SDK binary is executed - instead of always looking up the sub-package's `node_modules`, we should be looking at the `node_modules` closest to where the Functions SDK dependency is declared. This setup seems common in scenarios where the developer bundles the functions source using bundlers like vite/webpack/etc. This kind of technique has shown to help [AWS lambda's cold start time](https://aws.amazon.com/blogs/compute/optimizing-node-js-dependencies-in-aws-lambda/), and I think it's something we'd want to explore in Google Cloud Functions too.
Today, the CLI uses the
npm ls firebase-functions
command to check the version of the firebase functions of the user's functions module. The current implementation doesn't work when using npm/yarn workspaces.We rewrite the implementation to use [
require.resolve
] to look up location of the firebase functions package and read the accompanying package.json to look up the version instead. This implementation works with npm/yarn workspaces as demonstrated in the new test cases.Hopefully addresses #5191