3

I'm having an issue loading an Angular 2 application after I've moved a few components from one module to another. My guess is that I'm doing something wrong in the code itself however the error I'm getting is not helpful and I don't know if it's an issue with Angular or Webpack.

Error when loading application:

Uncaught TypeError: Object prototype may only be an Object or null: undefined at setPrototypeOf (<anonymous>)

That is the error that I'm getting when the application is loaded. I know that the issue is somehow related to the services in the application but I'm not sure what is happening. This is where the application is failing:

enter image description here

What has caused the issue?

I have four modules within my application:

  • AppModule
  • CoreModule
  • SharedModule
  • FeatureModule

It is my aim to follow the Angular guidelines with regards to Modules. I had set the above listed modules a while ago and I noticed that I was using the CoreModule incorrectly. Apart from providing the services to be used in the application I had put "generic"/"reusable" components in this Module as well.

After reading the FAQs specifically about feature modules I set about moving these components to the SharedModule. Now most of these components make use of the services in the CoreModule. Once I moved these components to the SharedModule and updated the necessary code I began to encounter this issue.

Currently the modules I have are set up in the following way:

  • AppModule imports the necessary modules along with the CoreModule and the FeatureModule
  • CoreModule provides the services to be used in the application
  • SharedModule declares and exports the generic components
  • FeatureModule declares the components to be used in the specific feature

I'm not sure if I'm importing the wrong module in the wrong place, but I can't figure out why I'm getting this error simply because I moved a component from one module to another. I can't really understand the error which is making it difficult for me to understand what is wrong.

Setup versions:

  • Angular: 4.0.1
  • Webpack: 2.3.3
  • TypeScript: 2.2.2

Further investigation

As mentioned above with the current setup I have most of the services being used across the whole application in one CoreModule (core folder). The components using these services are in a SharedModule (shared folder). When these components resided in the same module and folder everything was working as expected.

Now when I moved these components in the SharedModule, at first I was getting errors like what is described here but I had already encountered this before and I simply changed the imports I have to reference the service directly instead of the barrel. Once I changed these imports I get the error shown above. Again I am lost as to what the problem is, I can't understand the error and the change I've done is that the components are moved to another folder and module to where the services reside. My suspicion is that somehow a circular dependency is created, but I'm not sure.

Community
  • 1
  • 1
Daniel Grima
  • 2,765
  • 7
  • 34
  • 58
  • Daniel, did you ever figure this out? I am having the problem now, rather suddenly. I will post back if I figure anything out. – Jim Barrett Apr 29 '17 at 16:23
  • Hi Jim, it's a bit of a frustrating issue. In my application it was mainly related to the use of barrels. The screenshot above was being thrown because I was importing the base class I had with a barrel something like `import { BaseClass } from '../../shared'`. When I changed it to `import { BaseClass } from '../../shared/utils/base.class'` it seemd to solve the issue. Is the structure of your application similar to what I describe in my question? – Daniel Grima Apr 30 '17 at 11:58
  • Also an issue I'm still having is that certain classes I have to import classes by referencing the "file directly" other classes I can use the barrel, whilst other classes it's fine to use the barrel. I've read a few comments that it is known that barrels cause some issues at times. Also I'm still not sure whether I have some sort of circular dependency. I have it "solved" for now, but after I did the changes I described above I'm still not totally convinced whether the problem is caused because of barrels or something else I have set up. – Daniel Grima Apr 30 '17 at 12:05
  • Hi Daniel, thanks for getting back. Short answer is I have not figured this out yet but I will share my findings to keep things going in case you or others have additional ideas. I was using AotPlugin for both my dev and AoT builds, the former using `"skipCodeGeneration": true` which in effect makes it a non-AoT build. Both builds would complete but then both would fail at the function in your image `extendStatics(d, b);` and the previous entry in the stack pointed to the base class of one of my classes... I switched the dev build use `['awesome-typescript-loader', 'angular2-template-loader']` – Jim Barrett Apr 30 '17 at 18:14
  • ...and this fixed the run-time error for my dev build. However, using AotPlugin for the AoT build is still broken. It seems to have something to do with order of imports because when I was using the AotPlugin for dev builds if I moved the import of one of my components higher in my route.config file it actually worked at run-time. This makes no sense given that the point of module loading is to not have to worry about this stuff. I only have 2 modules, the main one and one that I lazy load. – Jim Barrett Apr 30 '17 at 18:37
  • Given that moving an import 2 lines up in one my source files actually fixes the problem means that I have just about zero chance of figuring this out and it would be like chasing ghosts. I may try to put small project together that repo's the problem and put it in an AngularCli Github. If you have something small and reproducable maybe you could do the same. For now, can't do an AoT build with my current code base. Have you given any thought to changing the title of this issue to include "base class" and/or "extendStatics"? It may help. – Jim Barrett Apr 30 '17 at 18:39
  • Thanks for your comments Jim. Yes I've also had times where changing the order of the imports did affect whether the application builds or not. I'll definitely update the question title. Note that I've first had the issue with a single base class, then once I fixed that I started having issues with my services. To be honest I haven't delved into AoT yet, I was meaning to give it a try as I know it has numerous advantages. Also as you suggested I'll try to find some time and try out a small application to see if the issue still persists. – Daniel Grima May 01 '17 at 06:27
  • Do you have a github repo fot reproduction? – yurzui May 01 '17 at 06:32
  • It seems there is a repo and both a TypeScript issue (closed) and open Angular Cli Webpack issue. The repo does easily reproduce the problem which is better than my case and Daniel's case where it seems to happen randomly based on import order. Here are the links... Repo: (https://github.com/jsayol/typescript-issue-14734) , Angular Cli/Webpack (https://github.com/angular/angular-cli/issues/5769), TypeScript (https://github.com/Microsoft/TypeScript/issues/14734) – Jim Barrett May 02 '17 at 03:25
  • 1
    To follow up again on how I fixed the issue in my code. I had `ClassB` derived from `ClassA` so it had to import `ClassA`. I had an `export enum MyEnum` in `ClassB` that `ClassA` also needed so `ClassA` had to import `ClassB`, hence the circular reference. To solve the issue I moved `export enum MyEnum` to a separate file (module) so that `ClassA` imported that instead of importing `ClassB`. I still think the original code should be handled by the module loader but in this case sticking to the "module per file" rule fixes the problem. – Jim Barrett May 04 '17 at 13:20
  • Thanks for the comment Jim. I still haven't had time to create a sample project with the set up that I have, been busy with other things lately. Hopefully I'll find the time to investigate this properly. Will definitely post updates once I have any information. – Daniel Grima May 04 '17 at 14:33

0 Answers0