-
Notifications
You must be signed in to change notification settings - Fork 400
Log with bunyan #327
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
Log with bunyan #327
Conversation
package.json
Outdated
"start:disco": "better-npm-run start:disco", | ||
"start:search": "better-npm-run start:search", | ||
"start:disco": "npm run version-check && NODE_PATH='./:./src' NODE_APP_INSTANCE=disco node bin/server.js", | ||
"start:search": "npm run version-check && NODE_PATH='./:./src' NODE_APP_INSTANCE=search node bin/server.js", |
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.
Nice, i was begginning to get to the point where I was thinking we should kill all the app specific start up stuff in favour of just using NODE_APP_INSTANCE
(aside from maybe the dev things for convenience).
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 refactored this to have a start
again so once the deployments are updated to use NODE_APP_INSTANCE=disco npm start
we can remove the old start:disco
commands.
If we get to a point of having log code in shared code presumably bunyan could do the right thing contextually? |
src/core/server/base.js
Outdated
global.CLIENT = false; | ||
global.SERVER = true; | ||
global.DEVELOPMENT = env === 'development'; | ||
global.DEVELOPMENT = isDevelopment; |
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 can kill these and the definePlugin versions of the same in the webpack conf since the config exposes what we need. Also I'm not sure if we need the CLIENT and SERVER ones? Maybe those are still useful?
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.
They don't seem to be read anywhere, I've removed them.
r+wc looks good. |
I'm not sure it's designed to work in the browser but I can look into it. What would the right thing be? Logging to console or sending them to a server? |
So I tried including bunyan in a client view and webpack blows up because it can't find |
It should work see trentm/node-bunyan#282 you might need to do this though trentm/node-bunyan#282 (comment) |
We'll want just any browser logging to point to the relevant console log func. It'll probably make sense to minimize the format a bit so there's not too much data displayed. |
Can deal with it later on though since this is ready to land. |
Server logging with bunyan, we don't currently have any client side logging other than printing an error if redux state fails to load.
Fixes mozilla/addons#9547.