Closed mwbrooks closed 10 hours ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 91.66%. Comparing base (
278514f
) to head (a24f387
). Report is 1 commits behind head on main.
🚨 Try these New Features:
We can merge this whenever, but I'm hoping we can instead separate
stdout
andstderr
as part of the default hook protocol on the CLI side of things 👀 IMO debug printing possible warnings would be more ideal for finding odd configurations or other errors that might cause later problems with hooks.
I'm also very much in favour of updating the Slack CLI to separate stdout
and stderr
. We may also want the combined output and possibly the error code.
It would be nice to have a future where all stdout
and stderr
are printed to --verbose
while select output is displayed in the standard output. This would allow developers to debug while keeping the normal CLI output cleaner.
I also share the concern that meaningful warnings could be suppressed. For example, I think NODE_NO_WARNINGS=1
will also silence console.warn(...)
which could be used by developers and the Bolt Framework for debugging.
That shouldn't block this, but I'm thinking we can revert these changes if that lands while these warnings are only appearing in unsupported Node versions?
I'm in favour of reverting this once we improve the CLI as well!
I'm also wondering if we improve testing in later PRs to exercise the hooks in multiple versions of multiple runtimes 😉
We should. I imagine the hooks package should support the same node versions that the Slack SDK and Bolt Frameworks support?
It would be nice to have a future where all
stdout
andstderr
are printed to--verbose
while select output is displayed in the standard output. This would allow developers to debug while keeping the normal CLI output cleaner.
Wow! Mirroring stdout
in debugs is a fantastic idea! Filtering with the tagged INFO
or ERROR
will be so helpful 😭
I also share the concern that meaningful warnings could be suppressed.
I'm hoping to start a PR that separates these outputs soon! I hadn't thought about the console.warn
suppressions, but these are the edges I fear so much 😉
I imagine the hooks package should support the same node versions that the Slack SDK and Bolt Frameworks support
Right now I think we're testing these versions alright, but I don't think we test that an actual npx slack-cli-get-hooks
call returns just the JSON. That might be difficult to test for some hooks that depend on app setups - start
- but a single test for get-hooks
might catch regressions from warnings like this!
This might also not be a problem after hook enhancements!
I left another comment about testing (not necessarily supporting) the current Node version to make upgrades to the next LTS a bit easier, but that might be discussion for future changes! 🤔
This does seem good to merge as is though! Please of course feel free to tag a release too if you'd like. Or let me know if that's a tag I can make. I still plan to follow up with reversions and revisions in the CLI, but let's not block improvement here 💪
Summary
This pull request updates the
@slack/cli-hooks
to silence the node process warning output.The reason for this update is that warnings can break some hooks, such as
get-manifest
, because the output must be valid JSON and the warning message is plain-text. For other hooks, such asdoctor
the warning is displayed to the user when the CLI command is executed, which can be confusing. I've left the warning forstart
because the user's code may need to print warning messages to the console.Example of a node warning message
This is an example using node v23.2.0:
Expected
get-hooks
JSONReviewers
Requirements (place an
x
in each[ ]
)