-
-
Notifications
You must be signed in to change notification settings - Fork 49
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: Adapt to serverless@3
logging interface
#174
feat: Adapt to serverless@3
logging interface
#174
Conversation
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.
LGTM thanks!
this.v3Utils.log.warning(msg); | ||
} else { | ||
this.v3Utils.log.notice(msg); | ||
} |
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.
Doing a string search is probably fine for this PR, but I think it's best for the caller to decide between .warning()
and .notice()
.
Was there a similar this.serverless.cli.warn()
in v2?
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, there wasn't a cli.warn
previously and only with this new logging mechanism we've introduced proper logging levels.
I fully agree that called should be responsible for deciding the log level of the message, but on the other hand I wanted to keep the changes as small as possible. What do you think makes more sense from the perspective of the plugin here?
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'm happy to do a refactor after merging this PR in. Thanks!
Need to sign off, but will investigate build errors:
|
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.
@pgrzesik - is v3utils
available at this time?
The docs say they should exist, but when I tried it out on neverendingqs:temp/v3utils, it wasn't defined:
$ npx serverless@pre-3 package --stage production
v3Utils exists: false
Serverless: DOTENV: Loading environment variables from .env, .env.production:
Serverless: DOTENV (WARNING): if "include" is set, "exclude" is ignored.
I would like to understand why my test is not working as expected before merging if you have a chance.
Hello @neverendingqs - thanks a lot for review, I was off for holidays but I'm back tomorrow and I'll see what might be going on in your case & in the build errors |
Thanks for the review @neverendingqs - as for the build errors - they're caused by As for your issue with |
…-interface # Conflicts: # package-lock.json # package.json
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.
Thanks for the review @neverendingqs - as for the build errors - they're caused by
--env
flag that is no longer supported in Frameworkv3
- this is even listed inREADME.md
that this flag will be no longer supported.
Thanks. Sorry I realized this between the two messages, and updated the README with this information.
As for your issue with
v3Utils
- I tried to reproduce but couldn't, for me it worked well, could you please check if you're not using some outdated version ofv3
prerelease?
That was it thanks! npx
was using a local copy of serverless
which was at version 2.
Thanks a lot @neverendingqs 🙇 |
Description
Adapts to new logging API that is going to be introduced with
serverless@3
.The change in scope of this plugin is fairly minor - I didn't want to change too much of the current logic, just to adapt it a bit to the new API. I'd be happy to hear about potential suggestions for improvements though 💯
Closes: #171
Checklist