Console clearing removes CRA’s own warnings

[denis-sokolov]

react-scripts start continuous scrollback clearing (#2495) clears the warnings CRA itself prints. Here is a visual demonstration slowed down:

On a faster setup it is near impossible to read the warning before it disappears.

Platform: node 10.15.3, npm 6.9.0
Search terms: clear, console, warning, 2495.

Steps to Reproduce

1. npx create-react-app my-app foo --typescript
2. cd foo
3. Delete allowSyntheticDefaultImports option in tsconfig.json
4. npm start

Expected Behavior

Ideally react-scripts would not clear the scrollback (#2495) and let the user see the logs of what happened in the past. Given the resolution of that issue this is unlikely.

Alternatively, react-scripts should take a lot of care to not clear its own warnings.

[bugzpodder]

The warning message should probably be shown after the console clear.

[mrmckeb]

@denis-sokolov, would you like to raise a PR for this? As @bugzpodder we recognise that this could be improved.

[denis-sokolov]

Unfortunately, I will not be making a PR to solve this, but I’m happy I brought this to your attention.

[hoylemd]

Another option would be to make the clearing optional. I really would prefer that it not clear the console, as I'm usually running it in a docker container via docker-compose, and it clears the log for the whole constellation, so I can't see if other containers had startup issues.

[NonLogicalDev]

The fact that react-scripts has the audacity not to just clear screen, but clear the scrollback is mind-boggling.

As a workaround though for those of you using iTerm there is a way to disable this VT100 functionality. Thank you, thoughtful iTerm developers.

Check the settings of your terminal emulator, there is a chance they have something similar.

[silverwind]

Console clear must be removed, it's so disruptive and unrespectful to the user to wipe all their previous terminal context which may even result in data loss in some cases.

I do currently workaround via npx react-scripts start | cat.

[harrislapiroff]

+1 to making console clearing optional. This is really messing with my docker-compose workflow.

[thijsrausch]

Any progress on this? I have seen multiple issues and PR's (meaning there must be a need), but the only 'solution' so far is a work around which doesn't work on Windows machines. Thanks

[unphased]

I've gone through #2495 and it's quite clear to see that the project maintainers are specifically attached to this user-hostile behavior of deleting their terminal scrollback data.

As well-evidenced in the discussion seen in another project, zloirock/core-js#548, project maintainers are well within their rights to reject proposals, ignore complaints, and so on. Perhaps the only thing of consequence that you can count on is the record shown as a reflection on the maintainers' relationship with and attitude toward users, which shines through brilliantly here.

I am here because a project that I'm now working on exhibits this well-documented undesired behavior, and I came looking for a way to configure it not to erase my terminal scrollback. This is relatively benign behavior, all things considered. We would do well to recenter ourselves and consider how selfsame little recourse we might have if the behavior was actively malicious, deleting more than what is typically fairly disposable terminal scrollback content. I should not need to remind everyone that we're all working with code and it would not be difficult at all for any project's maintainers to embed, or even conceal code that can do real irreversible harm by forking a few simple processes. It's all built on trust. All this open source business.

That was a long-winded way of saying that this appalling attitude being shown to well-meaning would-be contributors to the project has already damaged the trust, beyond repair, of many potential users of the software. That much is clear. That is how I feel now and I cannot imagine that there are no others who feel the same. From now on it would be a point of principle that I never touch this software, promote it to anyone I work with (regardless of its true merit!), and I probably will even actively take measures to remove it from being a dev-dependency on the project that I currently work with.

I guess it comes down to kindness being rooted in thoughtfulness about the impact of your actions on others.

[dougpagani]

This behavior is incredibly frustrating. I did not think it was possible for a software tool to be "audaciously unkind", but here is an excellent example. It's as if a browser extension implemented a "clear browser history" every time you loaded a page. Could you honestly imagine that being reasonably default behavior? Let alone behavior which is impossible to turn off?

Multiplexers don't even have a way implemented to turn off the scrollback-clear escape code, indicating that Jest's doing this is unprecedented across decades worth of TUI implementations.

There are two codes for clearing a terminal. \033[2J is reasonable to implement. But \E[3J? Why?

I have looked through the relevant issues here and I don't see a single justification from the team. Just the CRA maintainers closing any relevant issues with arbitrary reasons (feeding the command through a naked |cat is not a solution, as it ruins interactivity by unbinding the tty from stdin, which they built into the core of the program and so must know).

It may seem hyperbolic, but I think this is the most hostile ux design of a program I've seen that isn't intentional malware.

What's really irritating is that several PR's have been submitted which satisfy the preferences of the maintainers, yet they continue to deny them, saying there are valid workarounds. They then link to issues which show those workarounds, which are the workarounds which have bugs that the PR's they're commenting on specifically state they are trying to overcome with that PR.

If the maintainers want the default \033[2J + \E[3J behavior because they don't care about scrollback & prefer it nuked, fine, but what is the obstinate pushback against a toggleable environmental variable for the users for whom this is not preferred and is, to the contrary, very bad user experience? The code is already written.

The workarounds all involve piping through cat, which breaks stdin. So then CRA's suggested workaround is to neuter Jest's watcher facility?

Please leave the scrollback buffer alone. It isn't CRA's to nuke. Or at least merge-in one of the "everybody wins" PR's that are out there that do this with an environmental variable configuration. This is already a common pattern in CRA seen here.

---

EDIT: w/ links to the hostile-to-the-community issues I talked about

2017: PR which would make everyone happy
No response, it gets approved and not merged. Then it gets closed without a response from the maintainers.

2017: link
A maintainer says:

@drewswaycool @codepunkt @lmorchard @acusti @razzfox How do you feel about using concurrently as a workaround?
... which then draws a very clear answer from all participants of "no, this is not a valid workaround, but the suggested one would be"
To which the maintainer then responds:
Given that this issue is about providing a workaround to optionally not clear the console and several ways were provided to do so, I think we can finally resolve this issue. I don't see the need to further continuing this debate given the opinionated nature of CRA's defaults.

So why would CRA ask how the community feels about the workaround, if when they answer, CRA is going to say: "well too bad" and lock the issue? If CRA pleads with devs not to eject, and communicate what their challenges with the package are, why would they not just accept a PR like Use envar to disable clearConsole

2018-2019: 6102
With a lot of discussion, and the only thing said by a maintainer is:

This is done intentionally. We'll likely not merge this.
Closed with:
per #2495 (comment) several workarounds were provided for optionally not clearing the console. At this time, we will not consider adding an additional flag or changing the default within CRA. Thanks!

Which workarounds? What is linked is that original workaround, which was met with a chorus of "this is not a valid workaround".

Again, this could just be solved by merging one of the PR's such as 2495

[willxy]

Clearing the current window/screen is fine. Clearing the terminal's scrollback buffer is VERY NOT OKAY.

Please leave the scrollback buffer alone. It isn't CRA's to nuke.

I can't reiterate that enough. The terminal's scrollback is not CRA's to erase. The reason I have a scrollback buffer is to scroll back and see things. The user's scrollback buffer belongs to the user, and clearing it without permission is claiming ownership of something CRA does not own, outside of its purview.

Refusing to provide an option to avoid clearing the scrollback, I just don't understand.

There needs to be an option to avoid clearing the scrollback. I don't know what else to say.