feat(logger): improve default log formatter ordering

[bilalq]

Description of your changes

This resolves #1568. The problem raised in that issue is that the log formatter outputs log lines with keys written in alphabetical order. In practice, that means they start off with the cold start flag, the function_arn, function_name, function_memory_size, and a whole bunch of other stuff that is not usually of interest. The actual log level and message are buried and need log lines expanded to be seen. Even when expanded, they're hard to visually spot at a glance. When viewing a log group in Cloudwatch or some other UI that truncates log lines, you effectively see no useful information at all.

This screenshot shows what the experience is like:

This change addresses the problem by surfacing log properties in order of usefulness. This is a subjective decision, and opinions may vary, but the order submitted in this PR should be preferable for the vast majority of users. The "at-a-glance" view of logs should now be actionable and help with log-diving and debugging. The actual information recorded is unchanged and log insight queries should still work as before.

The serialization order is well-defined in modern ECMAScript engines:

Serialization From the MDN docs on JSON.stringify:

Only enumerable own properties are visited. This means Map, Set,
etc. will become "{}". You can use the replacer parameter to
serialize them to something more useful. Properties are visited using
the same algorithm as Object.keys(), which has a well-defined order
and is stable across implementations. For example, JSON.stringify on
the same object will always produce the same string, and
JSON.parse(JSON.stringify(obj)) would produce an object with the
same key ordering as the original (assuming the object is completely
JSON-serializable).

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#description

And the note about what that order is:

The traversal order, as of modern ECMAScript specification, is
well-defined and consistent across implementations. Within each
component of the prototype chain, all non-negative integer keys (those
that can be array indices) will be traversed first in ascending order
by value, then other string keys in ascending chronological order of
property creation.

Source: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in

Related issues, RFCs

Issue number: #1568

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[boring-cyborg]

Thanks a lot for your first contribution! Please check out our contributing guidelines and don't hesitate to ask whatever you need.
In the meantime, check out the #typescript channel on our Powertools for AWS Lambda Discord: Invite link

[bilalq]

Hey, @dreamorosi. This is the PR related to #1568. Note that I did not check the My changes generate no new warnings box because I was unable to get the lerna build/tests working right on my machine to confirm. It may or may not have new warnings, but since I can't explicitly confirm, I thought it best to leave that box unchecked.

[dreamorosi]

Hi @bilalq thanks for the PR, as you can see from the checks above there are a number of tests failing due to the change of order of the fields.

In order to run them locally, I would recommend you to check the contributing document that you can find here.
After setting up the dev environment (npm run setup-local) as described here, you should be able to run the tests for the utility with npm test -w packages/logger or all the unit tests with npm test -ws, as described here.

If there's anything that we can improve in the document please let me know.

[dreamorosi]

Please see my previous comment about unit tests.

[am29d]

Hey @bilalq I wanted to follow up on the issue so we can fix the tests and merge your contribution. Is there anything I can help with? Happy to connect in discord of schedule a quick call to walk you through the setup. This will help us to understand the struggles of new contributors and improve the future community work 🙏. Let me known.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
38.6% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[dreamorosi]

Hi @bilalq, we are going to close the PR for now.

If you decide to continue working on it please reopen it.

[bilalq]

Sorry, I was away on travels these past few weeks. I'll reopen sometime in the next few days with the test fixes (or perhaps just documentation of the issues I've hit when trying to get them to run).