Angular-cli: Empty bundles when using AngularCompilerPlugin

[swimmadude66]

Versions

angular: 5.1.0
node: 6.10.0
npm: 5.4.6
Windows 10

Repro steps

• Take working AOT-compile-able project, change AotPlugin to AngularCompilerPlugin
• Run your build
• Observe that bundles are only 8kb

Observed behavior

The builds succeed, but the output files contain no code from the project. Example app.min.js file:

webpackJsonp([1],[function(n,c){}],[0]); 

Desired behavior

I would like to see my code in bundles

Mention any other details that might be useful (optional)

[mkoert]

Angular: ~5.1
Node: 8.9.1
npm: 5.5.1
Mac OS 10.12.6

I'm having a similar issue, though my bundles are larger, but all have the same value.

/******/ (function(modules) { // webpackBootstrap
/******/    // The module cache
/******/    var installedModules = {};
/******/
/******/    // The require function
/******/    function __webpack_require__(moduleId) {
/******/
/******/        // Check if module is in cache
/******/        if(installedModules[moduleId]) {
/******/            return installedModules[moduleId].exports;
/******/        }
/******/        // Create a new module (and put it into the cache)
/******/        var module = installedModules[moduleId] = {
/******/            i: moduleId,
/******/            l: false,
/******/            exports: {}
/******/        };
/******/
/******/        // Execute the module function
/******/        modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/
/******/        // Flag the module as loaded
/******/        module.l = true;
/******/
/******/        // Return the exports of the module
/******/        return module.exports;
/******/    }
/******/
/******/
/******/    // expose the modules object (__webpack_modules__)
/******/    __webpack_require__.m = modules;
/******/
/******/    // expose the module cache
/******/    __webpack_require__.c = installedModules;
/******/
/******/    // define getter function for harmony exports
/******/    __webpack_require__.d = function(exports, name, getter) {
/******/        if(!__webpack_require__.o(exports, name)) {
/******/            Object.defineProperty(exports, name, {
/******/                configurable: false,
/******/                enumerable: true,
/******/                get: getter
/******/            });
/******/        }
/******/    };
/******/
/******/    // getDefaultExport function for compatibility with non-harmony modules
/******/    __webpack_require__.n = function(module) {
/******/        var getter = module && module.__esModule ?
/******/            function getDefault() { return module['default']; } :
/******/            function getModuleExports() { return module; };
/******/        __webpack_require__.d(getter, 'a', getter);
/******/        return getter;
/******/    };
/******/
/******/    // Object.prototype.hasOwnProperty.call
/******/    __webpack_require__.o = function(object, property) { return Object.prototype.hasOwnProperty.call(object, property); };
/******/
/******/    // __webpack_public_path__
/******/    __webpack_require__.p = "/";
/******/
/******/    // Load entry module and return exports
/******/    return __webpack_require__(__webpack_require__.s = 2);
/******/ })
/************************************************************************/
/******/ ({

/***/ 2:
/***/ (function(module, exports) {



/***/ })

/******/ });

[banjankri]

Are there any updates on it please? Will it be fixed in the coming release or maybe a workaround available?

[swimmadude66]

I think I may have found my issue. AngularCompilerPlugin seems to find different type errors (even when typechecking is set to false) than AOTPlugin. The Empty bundles were happening because I was getting suppressed type errors. I tried removing ALL types packages from my dev dependencies and suddenly I was getting bundles. I was able to solve most warnings by adding in (at)types/node(at)latest (even though the app is using node v6, and originally the types for that version)

Still very strange, but it does appear after updating a few repos that the issue was suppressed errors. Exposing them (I used a console log in my webpack callback) and fixing them eventually gives working bundles.

[banjankri]

This worked for me as well, thanks for the tip!

[JonWallsten]

I noticed something similar, when I started a new project with Angular Starter and merge our old code I got a bunch of type errors previously suppressed. I have no idea why they suddenly appeared though. But it's clear that they caused the empty bundle. I got however no indication at all that something was wrong. Not even with all kind of debug info turned on.

[kirkhoff]

I'm having the same issue as well, but removing all @types from package.json didn't fix it for me.

[tavelli]

@swimmadude66 thanks! can you give more detail on how you're logging the type errors?

I used a console log in my webpack callback

[swimmadude66]

@tavelli I call webpack from gulp (still transitioning to an all webpack mindset) so I used this as my webpack call:

return webpack(config, function(err, stats){
        if (err) {
            console.error(err);
        }
        if (stats.hasErrors) {
            if (stats.compilation.errors) {
                stats.compilation.errors.forEach(function(e){console.error(e,'\n');});
            } else {
                console.log(stats);
            }
        }
        return done(err);
    });

[tavelli]

i gotcha. so i added this in my webpack config
stats: "verbose"

which i think should dump any errors, but not getting any, it just sort of silently fails and produces bundle similar to @mkoert

also tried cli flag --display-error-details and still nada!

[kirkhoff]

Update on my situation, and the steps I took to fix this issue for my build...

TLDR:
Add the following rules to your tslint.json file and then resolve issues from your build.
https://github.com/angular/angular-cli/blob/d5d0b07812dd7ae73dcdd89d140a797c1359acd4/docs/documentation/stories/1.0-update.md#linting-rules

I wasn't able to get anything to log at all. No errors were thrown by webpack or during runtime (runtime was just blank, because there was nothing bundled). So, I decided to go nuclear and replace webpack with the angular cli in my existing project. In a separate directory, I started a new ng project using the cli. After pulling in .angular-cli.json and modifying a few fields in there to match my project, I also pulled in the following:

• tsconfig.json (direct replacement in project root)
• tsconfig.app.json inside my src directory
• main.ts (direct replacement)
• environments/*
• tslint.json (direct replacement)

I then removed everything test-related from .angular-cli.json and also didn't move over test-related configs from the cli project, because our project uses Jest. I also removed a whole bunch of webpack-related dependencies. It's important to note here that prior to moving over tslint.json and tsconfig.json, I was able to run my app and see the same result - no errors, empty bundles, and a blank screen.

Then the fun began. I replaced my configs and ran the linter. The errors started pouring in. I fixed those issues and then ran my build to find more errors (due to the changes made by tsconfig). The biggest issue I had was:

import { Observable } from 'rxjs';

I converted that to:

import { Observable } from 'rxjs/Observable';

...and then had to import the operators and observers that my app relied on.

After resolving the errors, I ran the app and it worked. I still think that some error should have been thrown without having to update tslint, but at least I have an app that works again. I hope this helps anyone out there.

[tavelli]

great tip. i went less nuclear and just brought over the tsconfig.json from a default cli project which resolved it for me. trying to exist with pure webpack outside the CLI is becoming increasingly difficult though, feels like a loosing battle :(

[swimmadude66]

Well, I was about to close this issue, but now even with my own tips I cannot get this project to generate a non-empty bundle. Gonna try @tavelli 's approach and pull over the cli tsconfig

EDIT: That didn't work, but I found another common issue. If (like me) you use barrel files (index.ts) for your components and services, you may run in to an error when you import components from it into different modules.

For example, I have several layers of barrel files in my components directory. If I import {AppComponent} from './components' in my AppModule then import {DashboardComponent} from './components' in my DashboardModule, compilation will produce an empty bundle with no error logs whatsoever.

I have to assume it is related to my other issue on the angular compiler which tries to import ALL exported classes anytime any are fetched from a barrel file. Pointing the import statements to the specific component file fixed my issue in this project.

[VivekPMenon]

I was so stupid that I had "noEmit: true" in my tsconfig.json which resulted in exact same behavior (Successful execution, but empty bundles). It took 3 hours of debugging angular-compiler-plugin to finally realize that noEmit was the cause for this behavior in my case.

Just mentioning it here so that it may help any other person who did the same kind of stupidity.

[wmarques]

Hi, sorry for bumping this up, but it seems that we are running into the same issue in JHipster.
Here is a sample repo: https://github.com/wmarques/jhi-lazy-fail

Just run yarn build and you'll see that webpack just stops, without any error...
The error occurs when adding two lazy loaded modules in our app-routing module, otherwise with only one lazy loaded module, it works, that's so strange...
In dev mode we use other loaders and it works, the two chunks are correctly created, so it seems to come from the @ngtools/webpack loader.

Thanks for your help

[filipesilva]

I'm not sure if the problems in this issue are still current, but at this point the issue is a bit old and seems to include several different problems. If you're still having trouble can you please open up a new issue using current versions of the plugin and include a standalone reproduction please?

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}