Corresponding issue #688
Example project https://github.com/istarkov/esm-log-issue-example
I've invited you as project owner.
In the example if no imports are present at https://github.com/istarkov/esm-log-issue-example/blob/master/routes.js all console logs have output at gcloud stackdriver logs
Any import in this file causes to work only some subset of console log commands like console.log('simple string') but not console.log(array | object | or stringified object)
Thanks @istarkov!
This is related to our transformation of console use. When passing an identifier we replace console.log(foo) with our own runtime.global.console.log(foo). So the issue is that our runtime.global.consle (the same as import console from "console") isn't plugged into google cloud. I wonder if google cloud augments console methods?
I wonder if google cloud augments console methods?
Hard to say, from my knowledge google uses custom closed source node 8 runtime, so I think it's possible.
The only available information _The Cloud Functions Node.js 8 runtime is based on Node.js version 8.15.0_
I wonder if google cloud augments console methods?
AWS Lambda does*, to support CloudWatch. Google might do something similar.
(* not for node.js custom runtimes)
We copy methods straight over from console in some cases. I'll look into handling that in a more case generic way to enable things like without specific environment checks.
I wonder why console.log('simple string') works at all, but nothing else. maybe google replaced only certain "overloads"? weird ...
@istarkov is any of this working without esm: console.log(array | object | or stringified object)?
without import statement all is working fine even with esm
@dnalborczyk
I wonder why
console.log('simple string')works at all, but nothing else. maybe google replaced only certain "overloads"? weird ...
The esm avoids transforms when possible. In the case of console.log("string") we know we don't need to transform the console use so we skip it. However, we need to transform console.log(someValue) because the value could be a namespace object.
aaaaah, ok, makes sense. 馃憤
Confirmed google cloud is patching console methods. Here is their log:
function () {
// Prepare a log entry.
var entry = {
TextPayload:
util.format.apply(util, arguments).substring(0, MAX_LOG_LENGTH),
Severity: severity,
Time: new Date().toISOString(),
};
if (functionExecutionId) {
entry.ExecutionID = functionExecutionId;
}
// Start a new batch if the current one would grow too much.
if (currentLogBatch.Entries.length + 1 > MAX_LOG_BATCH_ENTRIES ||
currentLogBatchLength + entry.TextPayload.length >
MAX_LOG_BATCH_LENGTH) {
startNewLogBatch();
}
// Add the entry to the current batch.
currentLogBatch.Entries.push(entry);
currentLogBatchLength += entry.TextPayload.length;
triggerLogReporting();
}
Update:
Patch https://github.com/standard-things/esm/commit/195cb6c1e713bcd65a596c5d5242f5b429fd4d61
Update:
esm v3.2.12 is released 馃帀
Wow, thank you!!!! Incredible library and author!
BTW I've updated on latest 3.2.12 esm, switched on npm version, see https://github.com/istarkov/esm-log-issue-example
and logs are still not visible.
Is it possible that fix wasn't deployed to npm?
Doh. I tested the wrong scenario. Fixed with 3.2.13.