npm start only reports a single error on save

[gbishop]

Can you reproduce the problem with latest npm?

Yes.

Can you still reproduce it?

Yes.

Description

What are you reporting?

Start with a fresh app resulting from invoking create-react-app. Run npm start. See it startup normally. Now introduce a few errors. I deleted the close angle bracket on the second div in src/App.tsx but it could be anything. Save.

I only get a single error message.

Failed to compile.

./src/App.tsx
(11,11): error TS1003: Identifier expected.

Run tsc. Get 3 error messages.

test-app$ tsc
src/App.tsx(11,11): error TS1003: Identifier expected.
src/App.tsx(17,7): error TS2657: JSX expressions must have one parent element.
src/App.tsx(18,5): error TS1109: Expression expected.

Introduce another error, perhaps in a different file. Save. Note that you still only get a single error message. Run tsc and note that they all get reported.

I can't see any pattern to the error reporting. I'll sometimes have several errors in different files. They are reported one at a time and jump from file to file and back again without any apparent order.

Expected behavior

Tell us what you think should happen.

On save it should report all compile errors.

Actual behavior

Tell us what actually happens.

It only reports a single error regardless of how many there are.

Environment

Run these commands in the project folder and fill in their results:

1. npm ls react-scripts-ts (if you haven’t ejected):

test-app$ npm ls react-scripts-ts
test-app@0.1.0 /home/gb/tmp/test-app
└── react-scripts-ts@2.3.2

2. node -v:

test-app$ node -v
v6.2.2

3. npm -v:

test-app$ npm -v
5.1.0

Then, specify:

1. Operating system: Ubuntu 16.04

2. Browser and version: Chrome Version 59.0.3071.115 (Official Build) (64-bit)

Reproducible Demo

Push to GitHub and paste the link here.

https://github.com/gbishop/crats-error

By doing this, you're helping the Create React App contributors a big time!
Demonstrable issues gets fixed faster.

[DorianGrey]

This is caused by formatWebpackMessages.js.
It strips everything except the first error, since it expects the other errors to indicate the same source.
Without this restriction, the output would look like this:

Failed to compile.

./src/App.tsx
(11,11): error TS1003: Identifier expected.

./src/App.tsx
(17,7): error TS2657: JSX expressions must have one parent element.

./src/App.tsx
(18,5): error TS1109: Expression expected.

./src/App.tsx
(17,9): error TS7027: Unreachable code detected.

./src/App.tsx
(9,7): error TS2695: Left side of comma operator is unused and has no side effects.

./src/App.tsx
(17,9): error TS2304: Cannot find name 'div'.

./src/App.tsx
Module parse failed: /home/linne/Projects/crats-error/node_modules/ts-loader/index.js!/home/linne/Projects/crats-error/node_modules/tslint-loader/index.js!/home/linne/Projects/crats-error/src/App.tsx Unexpected token (34:8)
You may need an appropriate loader to handle this file type.
|                     " and save to reload."));
|         div >
|         ;
|         ;
|     };

Note that the react-error-overlay does the same as well, but separately. Just haven't spotted the source yet.

Technically, it's a feature of CRA.

[gbishop]

I had wondered if it was from upstream but I can produce multiple error messages in a simple CRA app. I tested that theory just this morning.

Now that I go back to prove it, I can't... I must have fooled myself somehow and I cleaned up when I was done so I can't see what I did.

[DorianGrey]

The upstream is equivalent in this case.

It shouldn't be that hard to change this behavior, but there are two issues that come to my mind:

1. I'd recommend to propose this change on upstream, instead of applying it exclusively to this fork. It'd make synchronizing even more complicated than it already is.
2. I've been working with a CRA-based playground for a while now (though I've ejected it), and in most cases, stripping of these failures isn't the worst idea in general. Consider your example - you've removed a closing bracket here. The first error message on the stack indicates that this identifier is missing so that the current expression is incomplete. Every other error on that stack is just raised because of the first one - i.e. if the first one gets fixed, every other will disappear as well. That's why this behavior is implemented - it's expected that one error may be the source of all errors mentioned. In quite a lot of cases, this expectation holds true. The major downside is that this filter mechanism is applied globally, not on a per-file level - as a result, in case there are errors in multiple files, only the first error on the global stack is displayed to the user.

As a result, I'd recommend to make a feature request on the main CRA repo - at least to change this filter mechanism to a per-file level instead of the global one.

[gbishop]

I agree it should be done on the upstream. I understand their motivation, particularly in the case of the simple error I introduced. But during a refactor on a multi-file project it was strange to get a single error in Store.ts. I fix that, then I get a single error in Controls.tsx. I fix that and get a single error in Store.ts again. I've had it switch between files seemingly at random. That feature should at least be made optional with a variable in .env. gb

…

On Wed, Jul 12, 2017 at 2:05 PM, Christian Linne ***@***.***> wrote: The upstream is equivalent in this case <https://github.com/facebookincubator/create-react-app/blob/master/packages/react-dev-utils/formatWebpackMessages.js#L126> . It shouldn't be that hard to change this behavior, but there are two issues that come to my mind: 1. I'd recommend to propose this change on upstream, instead of applying it exclusively to this fork. It'd make synchronizing even more complicated than it already is. 2. I've been working with a CRA-based playground for a while now (though I've ejected it), and in most cases, stripping of these failures isn't the worst idea in general. Consider your example - you've removed a closing bracket here <https://github.com/gbishop/crats-error/blob/master/src/App.tsx#L10>. The first error message on the stack indicates that this identifier is missing so that the current expression is incomplete. Every other error on that stack is just raised because of the first one - i.e. if the first one gets fixed, every other will disappear as well. That's why this behavior is implemented - it's expected that one error may be the source of all errors mentioned. In quite a lot of cases, this expectation holds true. The major downside is that this filter mechanism is applied globally, not on a per-file level - as a result, in case there are errors in multiple files, only the first error on the global stack is displayed to the user. As a result, I'd recommend to make a feature request on the main CRA repo - at least to change this filter mechanism to a per-file level instead of the global one. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#103 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMFfCldrEmB-GYOwAcgEtwZjxGfKPheks5sNQrggaJpZM4OQ6Dp> .

[gbishop]

This hack

  if (!process.env.ALL_ERRORS && result.errors.length > 1) {
    result.errors.length = 1;
  }

in the place you indicated above seems to allow me to optionally enable showing all errors.

[wmonk]

As this hasn't been updated for a while, I am closing this issue. Please re-open if we have an update.