-
Notifications
You must be signed in to change notification settings - Fork 87
DX enhancements - quieter logging on startup and polling, clickable URL in console #1372
Conversation
Size Change: 0 B Total Size: 232 kB ℹ️ View Unchanged
|
src/server/utils/cdnCache.js
Outdated
console.info(chalk.bold.cyanBright('CACHE INFORMATION')); | ||
console.info(message); | ||
console.info('To clear the cache, please delete this file:'); | ||
console.info(` ${chalk.bold.cyanBright(path.join('~', oneAppDirectoryName, cacheFileName))}`); |
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.
Can you replace the template literal with string interpolation? Doing so helps with performance in cases where the log is dropped and does not have to be evaluated. (Same applies to message
a couple lines above)
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.
do you mean replace with string concatenation?
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.
Like:
console.info('one-app-dev-cdn loading module map from %s', remoteModuleMapUrl);
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.
What if we just put this as a single line
"one-app module cache size 30mb. To clear, delete file"
I dont think the separator, title and all are necessary
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 agree with Matt, we could eliminate a lot of this.
src/server/utils/cdnCache.js
Outdated
@@ -26,15 +26,18 @@ export const oneAppModuleCachePath = path.join(oneAppDirectoryPath, cacheFileNam | |||
export const showCacheInfo = async () => { | |||
try { | |||
const stats = await fsPromises.stat(oneAppModuleCachePath); | |||
if (stats.size > 1024 * 1024 * 10) { | |||
console.warn(chalk.bold.redBright('🚨🚨🚨: Cache file size is more than 10MB. 🚨🚨🚨')); |
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.
Isn't this pretty common for large tenancies?
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.
Yah I don't think this warning is necessary, or should be up at 300mb
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 guess ill just delete it.
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.
Yeah, I'm not sure there is any cache purge either so even a small tenancy will eventually hit the limit.
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.
@smackfu the cache only keeps one copy of any file for a module. It doesn't not keep multiple versions. So if you only work on one tenancy, your cache size is pretty 'stable' because new versions of your modules replace old versions
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.
FYI further discussion with @code-forger revealed there is a bug in the caching deduplication for locale files, which is why I was seeing duplicate entries for the same module.
console.log('pollModuleMap: polling...'); | ||
console.info('pollModuleMap: polling...'); |
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.
lots of log level changes
how does this affect the log entries in production? are there some side effects we and users should be aware of? are they breaking? (e.g. searching through logs)
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.
Info is the default log level in production
src/server/index.js
Outdated
console.log('%s listening on port %d', context, port); | ||
console.info('%s listening on port %d', context, port); | ||
if (context === '🌎 One App server') { | ||
console.log('🚀 One App Server is running on http://localhost:%d 🚀', port); |
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 URL is only accurate in development, but will be logged in production
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 think we should actually add a new log level for cases like this. console.dev
It would require a change here:
customLevels: {
dev: process.env.NODE_ENV === 'development' ? 34 : 0,
log: 35,
},
This would allow us to have logs that are only for development, but not debugging, without carrying around this condition
(edit: pasted the wrong link earlier)
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.
For reference in the above, console.info
is 30
and console.warn
is 40
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 like the idea but i would use a native one like info
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.
@giulianok that kind of defeats the purpose of the level. the existing log levels (trace, debug, info, log, warn, error, fatal) all have practical cases in both development and productions. these would strictly be for development.
If the point is about using console though, @PixnBits also pointed out and I agreed we should replace out use of console[method]
with importing the logger and using logger[method]
. IIRC everything left in src that uses console[method]
is outside the fastify context. Anything within that context should be using fastify.log[method]
or req.log[method]
(if in the context of a request)
f820eff
to
6ebe800
Compare
src/server/utils/cdnCache.js
Outdated
console.log(chalk.bold.cyanBright(separator)); | ||
const fileSizeInMB = stats.size / (1024 * 1024); // bytes to mb | ||
const cachePath = path.join('~', oneAppDirectoryName, cacheFileName); | ||
console.info('Local module cache size is %sMB. To clear the cache, delete %s', fileSizeInMB.toFixed(2), cachePath); |
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.
should this be info? I feel like as this is a development only addition it makes sense to keep this logged out during the beginning especially as it is only logged once.
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.
Generally, the cache should be 'invisible' to the user, most build / run systems have caches in dev mode. You dont see yarn, lerna, webpack, or esbuild tell you how big there cache is every run.
However, if there is some odd behaviour, and we ask the user to run one-app at a higher logging level, this log is useful. Therefore it should be at info level
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 one could be a good candidate for the new logger.dev logging method
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.
Yes
log: 35, | ||
dev: 36, |
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.
log: 35, | |
dev: 36, | |
log: 35, | |
dev: process.env.NODE_ENV === 'development' ? 36 : 0, |
warn: 40, | ||
error: 50, | ||
fatal: 60, | ||
}, | ||
customColors: 'trace:white,debug:green,info:gray,log:blue,warn:yellow,error:red,fatal:bgRed', | ||
customColors: 'trace:white,debug:green,info:gray,log:blue,dev:green,warn:yellow,error:red,fatal:bgRed', |
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.
Is there a color we can use that we're not already using?
Maybe we should use magenta.
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 like magenta. but where do I find the list of accepted colors? I was trying with "orange" or "purple" but those didnt work
@@ -46,6 +46,7 @@ export default { | |||
warn: 'warning', | |||
log: 'notice', | |||
info: 'info', | |||
dev: 'dev', |
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.
dev: 'dev', |
This is a production config, so the logs shouldn't get here.
@@ -57,7 +58,10 @@ export const listen = async ({ | |||
port, | |||
}); | |||
|
|||
console.log('%s listening on port %d', context, port); | |||
console.info('%s listening on port %d', context, port); |
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.
console.info('%s listening on port %d', context, port); | |
logger.info('%s listening on port %d', context, port); |
All instances of console should be replaced with logger, not just when using logger.dev. Unless you come across one that's within the Fastify context, then fastify.log, likewise request.log when in the request context.
src/server/utils/cdnCache.js
Outdated
console.log(chalk.bold.cyanBright(separator)); | ||
const fileSizeInMB = stats.size / (1024 * 1024); // bytes to mb | ||
const cachePath = path.join('~', oneAppDirectoryName, cacheFileName); | ||
console.info('Local module cache size is %sMB. To clear the cache, delete %s', fileSizeInMB.toFixed(2), cachePath); |
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.
Yes
console.log(chalk.bold.cyanBright(separator)); | ||
const fileSizeInMB = stats.size / (1024 * 1024); // bytes to mb | ||
const cachePath = path.join('~', oneAppDirectoryName, cacheFileName); | ||
logger.dev('Local module cache size is %sMB. To clear the cache, delete %s', fileSizeInMB.toFixed(2), cachePath); | ||
} catch (error) { | ||
console.error('There was error checking file stat', error); |
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.
Don't forget to changes the other instances of console to logger
Description
when running one-app in node.env = 'development'
logging is cleaner on startup
hiding messages about bundle sizes unless they are critical
hiding messages about what ports the app is launching on
hiding messages about module map polling, unless something goes wrong
offer a clickable URL to the UI project in the command line
Motivation and Context
GitHub discussion about DX enhancements
How Has This Been Tested?
unit test
Types of Changes
Checklist:
What is the Impact to Developers Using One App?
they will see less logging in development