-
Notifications
You must be signed in to change notification settings - Fork 201
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
feat(sdk)!: remove logger #2060
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `Logger` resource basically doesn't add value, only complexity. It is a great example of redundant future proofing, so let's just get rid of it and make the word a better place! We can always introduce it later when use cases are clearer. Let me explain: the only way to emit a log right now in Wing is using the `log()` builtin function, which is jsified as a `console.log()` statement (both preflight and inflight). Now, we hijacked `console.log` in our runtime environments and mapped it to the standard logger of that environment. In the cloud (e.g. AWS Lambda), the "standard logger" is basically `console.log()`, so basically the implementation of the logger for these environments is a "no-op". In the simulator, since #1879, we can listen to `console.xxx` events that come from the VM, and map them directly to the simulator trace system, so there's no need to hijack `console.log` here as well. All in all, doctor says it's a classic (and severe) case of future proofing, where we get the exact same behavior with much less complexity and code to maintain (over 700 lines of code are not needed) ***== GOODNESS**. ## Misc `node-fetch@3` is an ESM-only module and cannot be imported into our VM (damn!). In the meantime, I've downgraded it to 2.x and opened a bug: #2059
Signed-off-by: monada-bot[bot] <monabot@monada.co>
staycoolcall911
approved these changes
Apr 13, 2023
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.
This was referenced Apr 13, 2023
ainvoner
reviewed
Apr 13, 2023
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Congrats! 🚀 This was released in Wing 0.10.0. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
Logger
resource basically doesn't add value, only complexity. It is a great example of redundant future proofing, so let's just get rid of it and make the word a better place! We can always introduce it later when use cases are clearer.Let me explain: the only way to emit a log right now in Wing is using the
log()
builtin function, which is jsified as aconsole.log()
statement (both preflight and inflight). Now, we hijackedconsole.log
in our runtime environments and mapped it to the standard logger of that environment.In the cloud (e.g. AWS Lambda), the "standard logger" is basically
console.log()
, so basically the implementation of the logger for these environments is a "no-op".In the simulator, since #1879, we can listen to
console.xxx
events that come from the VM, and map them directly to the simulator trace system, so there's no need to hijackconsole.log
here as well.All in all, doctor says it's a classic (and severe) case of future proofing, where we get the exact same behavior with much less complexity and code to maintain (over 700 lines of code are not needed) *== GOODNESS.
Misc
node-fetch@3
is an ESM-only module and cannot be imported into our VM (damn!). In the meantime, I've downgraded it to 2.x and opened a bug: #2059BREAKING CHANGE: The
Logger
resource is no longer available.By submitting this pull request, I confirm that my contribution is made under the terms of the Monada Contribution License.