Allow configuration for max lines when eliding filter output

[JacobReynolds]

What is the problem this feature would solve?

Being able to see the output of stack traces when running bun with --filter enabled.

What is the feature you are proposing to solve the problem?

Update the eliding functionality to support a user-provided max_lines property.

What alternatives have you considered?

None.

[jakeboone02]

I would add that it would be nice to be able to turn off eliding completely. It could be a separate option or incorporated as something like max_lines=0 means no elision.

[Unarray]

I would add that it would be nice to be able to turn off eliding completely. It could be a separate option or incorporated as something like max_lines=0 means no elision.

Or have a flag like PNPM (--stream and/or --reporter=append-only) to print outputs prefixed with the originating package directory.
In my opinion, the idea of using max_lines=0 as a way to disable is a bit too implicit. Using explicit flags like --stream or --reporter=append-only makes the intention clearer and aligns with existing tools (in my exemple PNPM) that developers may already be familiar with.

With the same flag as PNPM, the command can look like:

bun run --filter='@packages/*' --stream dev
# or
bun run --filter='@packages/*' --reporter=append-only dev

Demonstration of the given examples

PNPM

Docker compose

[Unarray]

While chatting on Bun's official Discord, I found a workaround to "disable" collapsing.

All you need is to pipe the stdout with tee.

bun --filter '*' dev | tee /dev/null

Note

We use /dev/null special file to not create a garbage file in our project

Result example:

Discord discussion quote & link

Discord discussion source: https://discord.com/channels/876711213126520882/1255292814573572228

---

- Jarred Summer

this isn't a good solution but
you can do

FORCE_COLOR=1 bun --filter '*' dev > out.log

---

- Unarray

Based on the same principle, we can also use tee.
tee is a command that takes the output of a standard output (stdout) and then does two things:

1. write it into a file
2. write it into the stdout

Now, by executing the following command, output will be displayed in your terminal and in the out.log file.

bun --filter '*' dev | tee out.log

To take this a step further, we can combine tee with the special /dev/null file (if it doesn't work on windows, try using NUL instead) which represents "the void". Anything written to this file will be deleted.

Now, we can do our command with as the output file /dev/null, and we no longer have a garbage file named out.log!

bun --filter '*' dev | tee /dev/null

Example result of bun --filter '*' dev | tee /dev/null

[RiskyMH]

We have a flag now thanks to @martinamps in #15837! You can use --elide-lines <num> (0 to disable).

[kravetsone]

We have a flag now thanks to @martinamps in #15837! You can use --elide-lines <num> (0 to disable).

i guess it should be enabled by default in @1.2

becaus elider lines is worth DX.

[mio-moto]

Can we inject that via environments? I'm using a very small terminal window where I'm fine with 10-20 elided lines, while one of my coworkers uses a terminal on the full height of their monitors and they like it to be longer. I think that, to some degree, feels a lot like user-choice.

Additionally it looks like the eliding seems to clear a bunch of lines that is (a really minor petty thing), different than bun run dev, when we do things like bun run --filter 'one-project' dev. Might be unrelated to this issue, but it would be nice if there wasn't eliding in place when just one project runs.

[martinamps]

@mio-moto hmm like BUN_CONFIG_ELIDE_LINES ? looks like there isn't a ton of precedence for dials making it to env vars but it'd be easy to add.. @RiskyMH what's your take on that?

[RiskyMH]

@mio-moto hmm like BUN_CONFIG_ELIDE_LINES ? looks like there isn't a ton of precedence for dials making it to env vars but it'd be easy to add.. @RiskyMH what's your take on that?

Seems reasonable - personally I think maybe bunfig option could be better

Also I remember seeing issue with CI's, as I think they should not limit anything

[martinamps]

yeah bunfig makes sense but previous commenter was (rightly) saying that it's also an engineer preference vs project preference hence the env override being useful

Can you link a CI issue? how does bun typically detect a CI env?

I have some cycles again I could close out a couple more things on this

[jakeboone02]

Probably related:

• --elide-lines should warn or be ignored, not error, in non-terminal environments #16286