Skip to content
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

Add name-prefix option #75

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

johanblumenberg
Copy link
Contributor

Description

This adds an argument, --name-prefix, that removes the prefix on each line, and only prints the package name before each package is run.

@spion
Copy link
Collaborator

spion commented Sep 30, 2019

We already have no-prefix and this mode. Can you explain the need for another one?

@johanblumenberg
Copy link
Contributor Author

We already have no-prefix and this mode. Can you explain the need for another one?

The difference is this:

With prefix: wsrun will print the name of the package, and prefix each line with |
With --no-prefix: wsrun will not print the name of the package, and it will not prefix each line with |

The first option might be annoying because it adds a prefix to each line.
The second option is lacking information about which package is being built. You can't see what output is generated by which package.

This new option will print the name of the package, but will not prefix each line.

Another option would be to change --no-prefix to mean not to prefix each line with |, but stil log the package name of each package when the package is being built. I think that would make more sense, but that would change the current behavior.

@spion
Copy link
Collaborator

spion commented Oct 1, 2019

The first option might be annoying because it adds a prefix to each line

Can you elaborate on that a bit? Let me explain what I mean by reasons why we have the two options:

  1. The decision behind the prefix character was that its easier to follow the line up to the package name, and its much easier to differentiate a package name line when it has effectively different indentation

  2. The decision to add the no-prefix version is to get a TTY with zero interference when running e.g. the jest interactive watch mode for a single process

Is the reason something like enabling easier copy-paste? If so we could consider just removing the pipe leaving in the indentation only...

For naming, I see the bind we're in. I think --line-prefix (i.e. --no-line-prefix) works reasonably well (If we could break backward compatibility there are better options)

@johanblumenberg
Copy link
Contributor Author

The difference to the --no-prefix option is that --no-prefix doesn't even print the package name at the start of the output of each package.

Let's say you have 10 packages, and you run wsrun test. One of the tests fail. Now you want to know which package it was that failed. There is nothing in the log that tells me which package that was executing the failing test.

So I want it to log like this:

packages/a
// output from a
packages/b
// output from b
packages/c
// output from c

The --no-prefix option gives me just the output, with no context:

// output from a
// output from b
// output from c

Using a prefix it gives me this output:

packages/a
 | // output from a
packages/b
 | // output from b
packages/c
 | // output from c

It's not a big problem to have the indentation on each line, but in some cases I would rather have it as is. I want the output to be the same as when running in a single package.

If I output JSON data, then I can't just copy paste.
If I have some tool that parses the output from a test, that tool will have to cope with the prefix when running using wsrun, but also cope with no prefix when running in a single package.
If I have a large log file with many lines, 3 extra characters on each line will add up.

@spion
Copy link
Collaborator

spion commented Oct 2, 2019

We generally like to avoid additional miniature options unless really necessary. I'm thinking, if we replace the pipe character with a space, we would keep most of the benefits while also allowing easier use of the output.

The only drawback here is backward compatibility but I think the change is minor enough.

If that change ends up being insufficient, we could revisit...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants