Cryptic error in build for production although regular build succeeds

[Gunnar]

Hi everyone!

I am currently puzzled in one of my Angular 7 projects that the build for production ("ng build --prod") fails with a cryptic error while the regular build still works fine. 

The error message sounds like this:

ERROR in : Error: Internal error: unknown identifier []

    at Object.importExpr$$1 [as importExpr] (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:22447:27)

    at ..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:10011:37

    at Array.map (<anonymous>)

    at InjectableCompiler.depsArray (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:9977:25)

    at InjectableCompiler.factoryFor (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:10041:36)

    at InjectableCompiler.injectableDef (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:10060:42)

    at InjectableCompiler.compile (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:10070:106)

    at ..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:22292:90

    at Array.forEach (<anonymous>)

    at AotCompiler._emitPartialModule2 (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:22292:25)

    at ..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:22285:48

    at Array.reduce (<anonymous>)

    at AotCompiler.emitAllPartialModules2 (..my-project\node_modules\@angular\compiler\bundles\compiler.umd.js:22284:26)    at AngularCompilerProgram._emitRender2 (..my-project\node_modules\@angular\compiler-cli\src\transformers\program.js:337:31)

    at AngularCompilerProgram.emit (..my-project\node_modules\@angular\compiler-cli\src\transformers\program.js:212:22)

    at AngularCompilerPlugin._emit (..my-project\node_modules\@ngtools\webpack\src\angular_compiler_plugin.js:870:49)

As I did not compile for production for a long time I have no clue which change might have caused the production build to brake. 

I already searched the Internet but none of the described possible causes seems to fit to my project. 

I also deleted already the node_modules folder and ran npm install again.

Also running "npm run ng build -- --prod" gived the same error. 

Do you have any idea how I could track down the root cause for the error? 

This error makes me a little nervous as I just wanted to start a big project on Angular. But with such cryptic compilation errors I am afraid to get into a dead end road with the other project one day, too. Because an Angular project that does not compile for production anymore is dead, isn't it?

[Sander Elias]

Hi Gunnar,

Don't worry about this locking you into a dead end. Those things are always solvable. 

The first thing to try is updating your CLI to the latest one possible `ng update @angular/cli --next` (leave off the --next if you are uncomfortable with beta tools)

After that, start with running an `ng lint`. 

If that doesn't help come back here.

I do need my hands on your project to be able to solve this. 

Regards

Sander

[Gunnar]

Hi Sander!

Thanks a lot for offering your support!! 

For me it is not that important to get this very project working again as it contains just a collection of different exercises that I coded in an online training for angular. So this very project is not worth that you invest time in it. 

But it is more important for me to get an idea about the risk to invest a lot of time and money using Angular 7 as basis for my next project - and if possible risks can be properly managed or mitigated. 

So I learned now that Angular projects could get into a state where the production build can fail while insufficient information about the reason is provided. 

If I understand you correcly, according to your experience this is not a fatal risk and issues with the compilation for production could so far always be solved with low costs, correct? 

And how would you approach such an issue? Can the compilation process be debugged or traced?

Kind regards

Gunnar

[Sander Elias]

Hi Gunnar

But it is more important for me to get an idea about the risk to invest a lot of time and money using Angular 7 as basis for my next project - and if possible risks can be properly managed or mitigated. 

All projects that use build-tools are prone to this kind of issues. This is actually not unique to Angular.

arned now that Angular projects could get into a state where the production build can fail while insufficient information about the reason is provided. 

Again, this is not unique to Angular, I have seen this happening to all sorts of projects. Especially when the original creator/maintainer has left. I think the risk with Angular is lower as for an average project.

If I understand you correcly, according to your experience this is not a fatal risk and issues with the compilation for production could so far always be solved with low costs, correct?  

Your problem (while not unique) is very rare. And yes. it can be repaired at low costs.

And how would you approach such an issue? Can the compilation process be debugged or traced?

Yes, the compilation process can be debugged and logged. I have done this. However, that is not something I would recommend.
What I would recommend, is start a fresh project, and copy in module for module, until you find the culprit. It is a bit of a drag, but this way you can figure out the cause of your issue quickly.
Also, if it’s a corrupted tool-chain this will fix it in itself.

BTW, you said you did the rm -fr node_modules yarn install cycle. But are you sure you removed your yarn.lock package-lock.json files?
One of the problems I once had in a project was that files in my yarn cache where damaged. so that cycle would pull in a corrupted dep.

Sadly this kind of problem is something a developer has to deal with. I have seen it in all kind of projects.
As soon as there are 3rth party tools and any kind of package manager, this will happen. Not unique to Angular, or even Javascript.

Regards
Sander

​

[Richard Freedman]

While this won't help you with your current compilation problem, I suggest that in the future, as a preventative measure, you do a production compile on a frequent basis.

Running the app in non-prod mode causes much of the code to be compiled on the fly in the browser at runtime, and, as you have found, misses many issues that will fail a full production compilation. For example, I had an issue yesterday where a component's template referred to a non-existent member variable.

So, you should probably do a production compile after the addition of any major feature, and more often if possible. One way to do that is to use a Continuous Integration (CI) sever, such as Jenkins or Hudson, set up to poll your SCM repo, and build whenever there are changes.

Frequent prod builds will alert you to these issues early, when there are fewer changes, and the problem is easier to find.

[Gunnar]

Yes, Richard, this is also what I thought: In future I should rather test frequently the build for production in order to prevent another case like that. 

So good to know this now, before starting my next project.

Thanks a lot for your feedback and thoughts!!

[Gunnar]

Thanks a ton, Sander, for your detailed and quick responses!!

You are right, I did not delete the package-lock.json. However unfortunately another try with deleting both, this file and node_modules, did not change the final result. 

 

However I got some more confidence by your response that even if I would face such an issue again in future that there will be somekind of solution at low or at least "not such high" cost. 

And last but not least:

Your responses gave me also the feeling of not being all alone with it, what also already helps quite lot. 

So I will not investigate any further for now as this is only a training project. 

Greetings from Berlin to the Netherlands!

​

[Gunnar]

Hi Sander, hi Richard!

Finally I got the mistake, when I faced it in my new project again:

The error had been caused by a parameter in a constructor of the DataService class, annotated as "Injectable". This parameter ("uri") had been added to provide the data-object specific relative path to a backend service, when this constructor is called by a child-class like UserDataService:

@Injectable({
  providedIn: 'root'
})
export class DataService {

  url: string;

  constructor(uri: string, private http: HttpClient) {
    this.url = environment.apiUrl + uri;
  }
..

This seems to be no issue for the development compiler. But the production compilation breaks. The reason seems to be that Angular does not know what to inject into the uri parameter as actually there is nothing to inject. And this parent class shall not be injected anyway, but only its childs. But I thought if a child class is injectable the parent class needs to be injectable, too. 
But this does not seem to be the case. 

Therefore I changed the coding now by removing the "Injectable" Attribute from DataService and making it an "abstract class". So only it's child classes are now injectable - without the "uri" parameter in the constructor. And this way everything seems to be fine now (at least the unit-tests are all green). 

And shame on me!!!

I recognized now also a warning in the compilation for production that told me:

activeWarning: Can't resolve all parameters for DataService in Z:/Data/Software_Entwicklung/EmPort/emport-ui/src/app/services/data.service.ts: ([object Object], ?). This will become an error in Angular v6.x

:-o

So I am so sorry for carelessly not mentioning this warning in my posting. I just did not understand it and did not assume that it could relate to the error later in the compilation process. :-(

Nevertheless equipped with your helpful advises, I..

• was able to track down the error by following your advise, Sander, to rebuild the project step by step again! (and yes, would have been easier by looking more carefully at the compilation messages..)
• have set up a versioning and testing structure to get regular fallback scenarios for future issues in place, like Richard advised. 

So thanks a lot for your helpful advises again and next time I promise to be more careful!

Best regards

Gunnar 

[Sander Elias]

Hi Gunnar,

I'm glad you figured it out.

Thanks for taking the time reporting your findings back. This might be useful for someone in the future running into similar problems.

Regards

Sander

[Rich - gmail]

Glad to hear that you solved your problem!

BTW, since you mention abstract classes....I had a similar issue recently, where I created an abstract base class for components (which I had never done before),
and annotated the abstract class with @Component. Similarly to your issue, this worked fine with a non-prod build, but failed with a prod build. Removing the un-necessary annotation fixed my issue too.

---

Rich Freedman

   

--
You received this message because you are subscribed to a topic in the Google Groups "Angular and AngularJS discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/mBM_xy4Vt-s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at https://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.