Also happens here, sometimes. Not 100% yet when exactly but I think when making changes that would need a reload of modules while running ng serve. I.e. when deleting a Component from the declarations array in SharedModule… this is just a guess. I’ll try to look deeper and update this issue.

Current workaround is to stop ng serve and execute it again. (although this needs a while to compile all the deps as esm5 again)

OK, so I have found the problem and I have a solution.

But first here were my diagnosis steps:

1. On running ng serve I can see that adal-angular4 is being processed

Compiling adal-angular4 : main as commonjs

but I noted that it was compiling the main property, which is unusual, as most Angular libraries will provide more modern formats like ES5 or ES2015.

1. When I ran the app, I saw the error reported, so I debugged and stopped on the error. Looking up the call stack I can see that the class trying to be instantiated by the injector is the AdalService. Looking at the code for this I see that it has not been modified by ngcc to include the static properties (AdalService.ɵfaca and AdalService.ɵprov) that the ivy DI needs.

2. Looking at the main entry-point (index.js) in adal-angular4, I see that it is not formatted as CommonJS but is actually ESM5. Ngcc expects the main property to point to code that is either CommonJS or UMD. Since this is neither ngcc is not able to process it correctly.

So the problem is that adal-angular4 is using the main property to point at ESM5 code, which is not strictly correct - or at least is outside of what ngcc can handle, out of the box.

The fix is fairly straightforward. We need to teach ngcc that index.js is actually an ES5 formatted file. We do this via an ngcc.config.js file at the root of your project, which for this case will look like:

module.exports = {
  packages: {
    'adal-angular4': {
      entryPoints: {
        '.': {
          override: {
            module: './index.js',
          }
        }
      }
    }
  }
};

What this is saying to ngcc is that the primary entry-point (".") for the adal-angular4 package should have the module property in its package.json overridden with the given value ("./index.js"). In other words, it is like patching the package.json with a new property. After adding this config, ngcc will process index.js as ESM5 (which is the format that ngcc expects from the module property), and the application will work correctly.

This still happens on 9.1.4 this should not be closed

Hey all. Since this bug was seen by weirdness in my library, I have released adal-angular4 9.0.0-beta0 that provides the correctly formatted package.

I can confirm problem still remains on version 9.1.4 after running ng build --prod

It helped us turn “optimization” into false in angular.json.

I have nowhere near the experience with Angular demonstrated in this thread, however I just experienced this issue when performing the basic Angular TOH app: I went as far as adding the HeroesComponent to my template at which point my browser pulled a blank page–I could access the resources in the dev tools–and the Error: Angular JIT compilation failed: '@angular/compiler' not loaded! showed in the console. It may be of note that I added the @angular/mamterial to the project before adding in any code.

Based on this thread and on the console suggestion, I added import "@angular/compiler"; to my main.ts and it made my title from my app-component show back up in the browser ; but my heroes-component is still missing from the compiled web page.

I couldn’t find the file to edit based on comment 605631297.

$ ng version
Angular CLI: 9.1.1
Node: 12.16.2
OS: linux x64

Angular: 9.1.2
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... router
Ivy Workspace: Yes

Package                           Version
-----------------------------------------------------------
@angular-devkit/architect         0.901.1
@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
@angular/cdk                      9.2.1
@angular/cli                      9.1.1
@angular/material                 9.2.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

Hope this helps to create repro scenarios.

Edit: I removed the import "@angular/compiler"; line from my main.ts and Ctrl+C’ed the ng serve --open. Upon coming back to it for more investigation and relaunching the ng server --open I observed the issue simply went away. Only reason I can think of is that I did all my work with an open ng serve and did not restart it. I’m guessing relaunching the command somehow triggered a reset (?).

Yep, the same problem is seen here when updating from 9.0.6 to 9.0.7. Also appears in 9.1.1.

@jrdutton - yes we are going to change the main property format sniffing to also look for ESM5 formats (currently it only considers UMD and CommonJS). That should resolve this issue. Not sure of the timeline for this but probably next week sometime.

Yep, the same problem is seen here when updating from 9.0.6 to 9.0.7. As above, setting aot to false is a workaround, but is certainly a step backwards.

Also appears in 9.1.0.

Same for us after updating to 9.0.7. Starts working if we set aot: false in angular.json, but that can’t be the fix, can it? Why is it working for us when we do the reverse of PriyaChotiya

Getting this issue. Fine on Angular 9.0.6 but issue appears on 9.0.7 and 9.1.0. Rolling back to 9.0.6, the issue goes away.

Solved in Angular 9.1.11 setting “enableIvy” : false. Tks @miranda-vic and @vt-d-developer

If you are upgrading an Ionic 5 project and getting this error take a look @ https://stackoverflow.com/a/60183174 seems you will need to update some of the ionic-native dependencies to work. One I updated mine this error went away.

@mistic100 - sorry about this. If you are able to, the best approach is to look at the stack trace at the point where this error is thrown. Further up the call-stack you might be able to find a point where it is trying to create a component. This should tell you, at least, which component template contains the offending component that has not been processed by ngcc correctly.

Another approach is to run ngcc across the whole node_modules directly with debug logging and see if there are any useful messages. Run node_modules/.bin/ngcc -l debug.

For people still seeing this issue: it is typically caused by one of these reasons:

1. libraries that are packaged in an unusual way such that ngcc is unable to process them to become Ivy compatible. Therefore, there’s no singular root cause, each of the misbehaving libraries might need a different solution, or might not be supported at all (for example, minified bundles cannot be supported). The tricky part is figuring out which library is failing to be processed, analyzing the stack trace may help here.
2. The ngcc compiler is has not been run. When using the CLI this should all happen transparently, however custom build setups may need to be updated to run ngcc manually.

For the first case, please try to figure out what library is a problem, then seeing if an updade is available or whether there’s an open issue with that library. If you can’t find any of that, please open a new issue here with a reproduction repo, preferably using a minimal Github repro.

@JulioBastidas ngcc should automatically pick up that file if it exists.