Errors are reported differently depending on when you execute `npm start`

[DeborahK]

🐞 Bug report

Command (mark with an x)

• new
• build
• [x ] serve
• test
• e2e
• generate
• add
• update
• lint
• xi18n
• run
• config
• help
• version
• doc

Is this a regression?

Yes. In Angular v8 and before, the browser would consistently show errors, regardless of when you executed `npm start`

Description

What you see in the browser when you have an error depends on when you execute `npm start`. You may get this:

No error shown. Appears to display the last successfully compiled files.

You may get this:

Get error. This is very unhelpful, especially for Angular beginners. This appears if you run npm start after making an error. It appears that it cannot serve any files in this case.

Or you may get lucky and get this:

This is much more helpful, but not consistently shown.

🔬 Minimal Reproduction

This is one example, but it happens with many different errors, such as forgetting to add a component to an Angular module:

1. ng new APM
2. cd APM
3. code .
4. Run npm start
5. Add the following line to the template: <input type='text' [(ngModel)]='listFilter' />
   (This is an error because we don't have listFilter defined and we have not imported FormsModule.)
6. View the browser. No error.
7. Using the F12 tools, you see the ngModel error.
8. Stop the compiler.
9. Restart the compiler and you see the black background and an error in the browser.
   I assume this is the behavior that we should see in every case.
10. Remove the added input line. The code does not recompile and the browser still shows the error. So it appears as if it was not fixed.
11. Stop the compiler.
12. Add the above input element again (step Concatenate all source files  #5)
13. Start the compiler.
14. This time you'll see the cannot get error.

So depending on when the npm start is executed, the developer will see different results, some of which, like the cannot get error, provide no information in the browser as to what is wrong.

🔥 Exception or Error

🌍 Your Environment

@angular-devkit/build-angular     0.901.1
@angular-devkit/build-optimizer   0.901.1
@angular-devkit/build-webpack     0.901.1
@angular-devkit/core              9.1.1
@angular-devkit/schematics        9.1.1
@ngtools/webpack                  9.1.1
@schematics/angular               9.1.1
@schematics/update                0.901.1
rxjs                              6.5.5
typescript                        3.8.3
webpack                           4.42.0

Anything else relevant?

Similar issues: #15887

[filipesilva]

Reminds me of angular/angular#32213, but that's been fixed I think.

[alan-agius4]

This is actually expected and it's not any different from that of previous versions with AOT compilations. It happens more often since version 9, because AOT has been turned on by default which results in more errors being caught during build time instead of runtime.

1. During AOT builds we only emit JS when there is no error. This results in the blank screen with a cannot get error when the 1st compilation is not successful.

   angular-cli/packages/ngtools/webpack/src/angular_compiler_plugin.ts

   Lines 1399 to 1413 in 348ebdd

   	if (!hasErrors(allDiagnostics)) {
   	time('AngularCompilerPlugin._emit.ng.emit');
   	const extractI18n = !!this._compilerOptions.i18nOutFile;
   	const emitFlags = extractI18n ? EmitFlags.I18nBundle : EmitFlags.Default;
   	emitResult = angularProgram.emit({
   	emitFlags, customTransformers: {
   	beforeTs: this._transformers,
   	},
   	});
   	allDiagnostics.push(...emitResult.diagnostics);
   	if (extractI18n) {
   	this.writeI18nOutFile();
   	}
   	timeEnd('AngularCompilerPlugin._emit.ng.emit');
   	}

2. The black overlay is shown when you had the application open in a browser and the above occurred.
3. When there is a compilation error on a rebuild we don't "block" the compilation, to have faster rebuild times, by the means of the "forkTypeChecker" (https://angular.io/cli/build), the downside of this is that errors will only be shown in the terminal. A user can opt-out of this by disabling the "forkTypeChecker" and they will get the black overlay, but this comes at the cost of rebuild times.

Overall we definitely need to look into this more and evaluate how we can improve/align the DX around errors, and see how others are using fork type checking and reporting errors back to the browser via an overlay such as:
https://github.com/ypresto/fork-ts-checker-async-overlay-webpack-plugin/blob/master/src/index.ts
https://github.com/TypeStrong/fork-ts-checker-webpack-plugin/

My current suggestion would be to use the terminal as the source of truth for build related errors.

[alan-agius4]

Edit: fork-ts-checker-webpack-plugin does suffer from the same "issue" - https://github.com/TypeStrong/fork-ts-checker-webpack-plugin#options (see async option description)

[DeborahK]

Thank you so much for looking into this and providing such detailed feedback.

This is going to really confuse beginners, who may think:

• For Typescript Broccoli Plugin doesn't pass error message to broccoli #1: "Why am I getting a cannot GET error, I'm not even issuing a GET request!"
• In the case of new command parameters should have better defaults #3: "I made some edits and they don't appear!".

I'd minimally suggest that this be included in the documentation: That they could see three different results depending on when they run the compiler and that the focus should be on the terminal window.

This should include the text of the error (in the case of #1) so that hopefully it would show up in search results.

This is what I had added to my course for beginners the first time I show them what will happen if they forget a step (such as forgetting to add a component to a module):

What you’ll see in the browser depends on when you last started the compiler with npm start.
• You may see the app component page title, but not our product list component. In this case, the browser displayed the last successfully compiled files, so you don’t see our new component. Using the F12 tools, no error is shown.
• Or, you may see the message “Cannot GET”. Opening the developer tools, you see the error is: “Failed to load resource: the server responded with a status of 404 (Not Found)”. You may see this error whenever the application can’t compile and therefore can’t serve the files to the browser.
• Or you may get lucky and see the actual error: “pm-products is not a known element”.
In any case, your best option is to go back to VS Code and view the terminal window to see any compilation messages. Whenever you see unexpected results or errors in the browser, check the VS Code terminal window for compile issues.

Thank you again!

[indraraj26]

Yes i am having similar issue sometime i get can not get / then i look into web browser console then i look into terminal for errors. This is started in NG9 (probably of AOT)