Completely silent mode

[josh-braid]

• [ ] I'd be willing to implement this feature (contributing guide)

Description

Currently, if I implement some script target using nx:run-commands, depending on a build target then no matter what, when I nx run it, it will include a certain amount of spam about the build process, caching etc.

It would be very nice to be able to have a --silent option for script targets that need to control their output. (Ideally on the executor so it doesnt need to be passed every time it's run)

Motivation

I'd like to avoid needing wrapper scripts that do nx build thing && node dist/{thingPath} since encoding that dependency is redundant and seems like it's exactly the thing you want a build system to do.

Suggested Implementation

Not sure about internally implementing it, seems like silencing output is straightforward. In terms of the interface, it would be nice to have both an nx run --silent <target> and also an option for "silent": true in the executor configuration (since script targets probably always want to suppress nx output).

Also, it'd be good if there is an error in the build that output does get printed, but only on error.

Alternate Implementations

I can keep wrapping nx calls with bash scripts, though that makes me kind of sad :(

[josh-braid]

Any update on whether this is planned?

[ryanouellette]

+1. I would also find this immensely useful for essentially the same reasons. It would be really nice to utilize nx run for building, if necessary, CLI tools and consuming their output without NX related noise going to stdout/stderr.

+1 to also being able to specify an option in the executor configuration to suppress the output by default for a target.

[qingquanwang]

+1

[lppedd]

Bumping it for visibility. Great feature imo.

[martin-mindflow]

This would be extremely useful for our CLI tools, and we'd be able to remove the little hacks we had to resort to to get plain outputs for commands (for example when we need to pipe one command to another)

[antoineviscardi]

As a workaround, I believe the following works

Instead of this, nx run some-project:wrapped-script --arg myarg > out.txt

do this, nx run some-project:wrapped-script "--arg myarg > out.txt"

I think this is still far from ideal and quite brittle, but if your piping is simple, it seems good enough.

[Tramb-dev]

I agree with you; it's unfortunate that we can't directly retrieve console output without all the additional data provided by Nx. I currently need this feature in my executor to fetch a raw string used by my CI. It would be beneficial to implement a functionality similar to the 'nx show projects' command, which outputs a string without the command line information that was executed.

[cxsimon]

+1 on this, the output of nx is spamming the cli controllers to a point where its impossible to load the pages via Jenkins

[hco]

I also would love this feature and thought about it a bit, too.

Also, it'd be good if there is an error in the build that output does get printed, but only on error.

I think this should be a bit configurable, e.g. which exit codes mean "error" and maybe also "if a specific string shows up in the output, consider it an error"

This would need to be implemented in rust right now, right?

[ClementMindflow]

Same here, invoking a CLI from nx is super powerful as it benefit out of the box of env var autoload and task dependency execution. However the amount of logs coming from nx makes this approach nearly un usable for large CLI with a lots of deps.

[FrozenPandaz]

We could look into implementing this as --outputStyle none.

[hco]

@FrozenPandaz Would that work on a per-target basis? Looking at the original ticket, the author probably has two targets: serve and build, serve depends on build and they only want to hide the output of build

[mrfelton]

100% on this. Kinda surprised this one has not been addressed yet. Presumably every single person that needs to do anything remotely complex with nx now has their own custom wrapper scripts to cut out all the nx noise and just get the output of a given command.

Here is a concrete example of a simple nx target that outputs some json, and the custom crap we have to wrap an nx run call with every time we run it.

Default (unusable) output:

❯ nx packages

> nx run zapmiddleware.lightning.api:packages

^D
["zaplightning"]

—————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————————

 NX   Successfully ran target packages for project zapmiddleware.lightning.api (2s)

Wrapped:

❯ nx packages | grep -o '\[.*\]'
["zaplightning"]

[mrfelton]

Cross linking a couple of similar requests/discussion for reference

• https://github.com/nrwl/nx/issues/1571
• https://github.com/nrwl/nx/discussions/15198
• https://stackoverflow.com/questions/77242066/how-can-i-remove-nx-default-output