-
Notifications
You must be signed in to change notification settings - Fork 365
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: determine duplicate function precedence based on extension #5623
fix: determine duplicate function precedence based on extension #5623
Conversation
📊 Benchmark resultsComparing with 17605fc Package size: 313 MB⬆️ 0.00% increase vs. 17605fc
Legend
|
@@ -222,9 +222,9 @@ export const startFunctionsServer = async (options) => { | |||
functionsDirectories.push(distPath) | |||
} | |||
} else { | |||
// The order of the function directories matters. Leftmost directories take | |||
// The order of the function directories matters. Rightmost directories take |
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.
Hmm, this feels unrelated to the extension precedence. Is this a separate problem you've identified?
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.
It is actually related. In zip-it-and-ship-it we have defined that the rightmost directory takes precedence. Since me reversing the array in this PR is mimicking ZISI behavior, it meant that we had to also use that same logic here in the CLI.
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.
But we're reversing the array of the functions that come out, not the list of directories going in?
(Sorry if I'm missing the point.)
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.
No worries! I'll try to explain it better.
Previously:
In the CLI we were passing the following to ZISI:
directories: [user-func-dir, internal-func-dir]
This meant that zisi returns a list of functions with the following precedence:
user-func-dir/hello.ts
user-func-dir/hello.js
internal-func-dir/hello.js
This is because ZISI will let functions from the rightmost directory take precedence. (fun fact: we pass the internal folder first in netlify/build as well)
That wasn't a problem before in the CLI, as we'd register the first function we'd encounter (in this case user-func-dir/hello.ts
), making the user function take precedence, just like we do in netlify/build
.
Currently
To make sure we get the same precedence as ZISI passes on to us, I reversed the functions array we got from ZISI before we register functions. But to also make sure that user functions take precedence like they did before, and like they do because of the way we pass the internal-func folder first in netlify/build
, I also had to change the way we pass the sourcedirectories.
Otherwise we'd first register the internal-func-dir/hello.js
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
🎉 Thanks for submitting a pull request! 🎉
Summary
This again implements function precedence based on extension by reversing the functions array so it behaves similar to how production works. I also had to reverse the way our sourcedirectories are passed.
For us to review and ship your PR efficiently, please perform the following steps:
passes our tests.
A picture of a cute animal (not mandatory, but encouraged)