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: detect a wider range of scheduled functions #1105
Conversation
⏱ Benchmark resultsComparing with 123e7e8 largeDepsEsbuild: 7.4s⬆️ 16.91% increase vs. 123e7e8
Legend
largeDepsNft: 35s
Legend
largeDepsZisi: 50.4s
Legend
|
scheduled functions which are reassigned or not directly exported are now detected
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.
Looks really good. I left some comments and questions, mostly related to the fact that traversing ASTs is tricky and we should go the extra mile to make sure stuff is easy to understand by our future selves!
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
Co-authored-by: Eduardo Bouças <mail@eduardoboucas.com>
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.
🚀
scheduled functions which are reassigned or not directly exported are now detected
This PR extends the functionality of the detection for the in-source-config of scheduled functions.
2 cases were not supported previously:
schedule()
helper but assigned to a variableschedule(SCHEDULE, ...)
export const handler = schedule()
) but instead assigned to a variable which is exportedexport { handler }
To solve both of these cases I opted to collect all variable bindings and their current value (only in the root scope). This is done by iterating through all nodes and collecting all declarations of variables and all reassigns. This method is memoized so that multiple calls (at the moment maximum 2) won't result in duplicated work.
Now, when the cron pattern in the schedule helper (1) or the export (2) is encountered as an identifier instead of the expected value, the code now can resolve the identifier to its value using the binding-map.