Stop hiding the column number of ESLint errors

[justingrant]

Currently, CRA's npm start output only reports the line number of ESLint errors but hides the column numbers. This makes it harder for IDE users to leverage the time-saving features provided by IDEs like VSCode to deal with build errors:

• devs can't one-click to navigate from the build error message to the exact spot in the code where the problem is.
• the code editor won't show the little red sqiggly line under the exact spot in the code where the problem is.

This PR removes one line of code (originally introduced in #5174 last year) that removes column numbers from ESLint errors. Here's the current code. As you can see, it has no side effects-- it removes column numbers but doesn't do any other changes to the string.

create-react-app/packages/react-dev-utils/formatWebpackMessages.js

Lines 44 to 46 in 4397d06

	// Remove columns from ESLint formatter output (we added these for more
	// accurate syntax errors)
	message = message.replace(/Line (\d+):\d+:/g, 'Line $1:');

Here's what existing errors look like:

./src/Calendar.tsx
  Line 19:  Unnecessary escape character: \.  no-useless-escape

Here's what errors will look like after this PR:

./src/Calendar.tsx
  Line 19:21:  Unnecessary escape character: \.  no-useless-escape

[justingrant]

BTW, I couldn't get the tests running on my Mac, so if this change breaks any tests then I'll fix 'em once Travis tells me where the breaks are. ;-)

[justingrant]

Thanks @ianschmitz. Sorry for all the Travis build spam. Last night Travis builds were all failing with network errors, e.g.

Command failed: yarnpkg install --mutex network
    error An unexpected error occurred: "http://localhost:4873/@types%2freact: no such package available".

Looks like Travis's problem was fixed by the time I tried to force-push the same commit again this morning. Thanks again!

[stale]

This pull request has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[justingrant]

Not stale. Hi @ianschmitz - You approved this PR a month ago, but it's still not merged. Is there anything I can do to help get it merged? And while we're talking stale PRs, #7022 to fix VSCode debugging is still waiting for a review. Is there anything I can do to help move it along?

[mrmckeb]

Hi @justingrant, this would be great for the next release. Can you rebase this and push again, so it runs through the updated CI - we can then get it merged.

[justingrant]

@mrmckeb - looks like @bugzpodder triggered a CI run (which passed except for a Windows 10 installation issue which I assume is unrelated to my PR). Do you still need me to rebase and push again?

[mrmckeb]

Yes please @justingrant, the PR is quite far out of date (which is our fault, sorry).

[justingrant]

Hi @mrmckeb - OK rebase is done. While we're talking about old PRs, what's the latest status on #7022? Anything I need to do to get that PR reviewed? Should I rebase that PR too?