-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
tools: move message listener to worker objects #6212
Conversation
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event.
f0f20c1
to
dba59e6
Compare
CI is green except for a flaky test. |
LGTM |
2 similar comments
LGTM |
LGTM |
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: #6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Landed in 58561cf |
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: #6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: #6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: #6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
needs to land with 81fd458 |
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: nodejs#6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Moving the `message` event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x's `worker` parameter in the cluster object's `message` event. PR-URL: #6212 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
@mscdex would you be up for sending a PR backporting all the updated linter stuff in one place? It would likely have to wait for my current tap fix to land, but once that is in it may be nice to backport this entire section. Alternatively we could label this and others as don't land. Thoughts? |
ping @mscdex |
@thealphanerd Would it make more sense to just backport @Trott's eslint caching instead? |
@mscdex if that trumps this I don't see why not |
@Trott and I discussed no longer backported linter changes. Going to put this as don't land for now |
Checklist
Affected core subsystem(s)
Description of change
Moving the
message
event listener from the cluster object to each worker object allows easier backporting of the recent jslint changes since v5.x and older do not have v6.x'sworker
parameter in the cluster object'smessage
event.