angular-cli: ng build -aot error 'entry.split is not a function' on lazy loaded modules

OS?

Windows 10

Versions.

1.0.0-beta.20-4

The log given by the failure.

C:\Projects\Cli>ng build -prod -aot 10% building modules 2/2 modules 0 active entry.split is not a function TypeError: entry.split is not a function at Function.ModuleRoute.fromString (C:\Projects\Cli\node_modules@ngtools\webpack\src\plugin.js:24:27) at C:\Projects\Cli\node_modules@ngtools\webpack\src\plugin.js:244:34 at Array.map (native) at AotPlugin._processNgModule (C:\Projects\Cli\node_modules@ngtools\webpack\src\plugin.js:243:14) at C:\Projects\Cli\node_modules@ngtools\webpack\src\plugin.js:217:39 at process._tickCallback (internal/process/next_tick.js:103:7)

Mention any other details that might be useful.

I understand that this feature is still under development but FYI… Line 24 of node_modules/@ngtools/webpack\src\plugin.js var split = entry.split('#'); Looks like it expects SystemJs module path like my.module#MyModule But this format doesn’t work with webpack. In order to lazy load modules I use es6-promise-loader and it looks like this:

export function loadMyModule() {
  return require('es6-promise!./my.module')('MyModule');
}
export const appRoutes: Routes = [
    {path: 'my', loadChildren: loadMyModule},
]

So, the entry parameter of ModuleRoute.fromString (line 23) is not a string but rather something like this:

activeStaticSymbol {
  filePath: 'C:/Projects/Cli/src/app/app.routing.ts',
  name: 'loadMyModule',
  members: undefined }

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 2
Comments: 20 (10 by maintainers)

Commits related to this issue

fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to Meligy/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to Meligy/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to Meligy/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to Meligy/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to Meligy/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to angular/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to matsko/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to wKoza/angular by Meligy 8 years ago
fix(compiler-cli): avoid handling functions in loadChildren as lazy load routes paths The change avoids the compiler CLI internal API from mismatching the following case as lazy loading ``` import {... — committed to idlechara/angular by Meligy 8 years ago

Most upvoted comments

Sure. Both of the following have the fix (second is attempting to fix some other issues as well):

angular/angular#13676 angular/angular#13678

clydin on Jan 6, 2017

i have the same kind of issue with angular-cli beta-24 and angular 2.4.1

previously i had a errors like this ERROR in Error encountered resolving symbol values statically. Function calls are not supported. Consider replacing the function or lambda with a reference to an exported function but i fixed them using exported functions : loadChildrenXXX

here is what seems to be the source of the error :

 import { Routes } from '@angular/router';
 import { DashboardComponent } from './dashboard/dashboard.component';
 import { ExtensionsComponent } from './extensions/extensions.component';
 import { StoryModule } from './story/story.module';
 import { GeneralModule } from './general/general.module';

export function loadChildrenStory() {
    return StoryModule
};
export function loadChildrenGeneral() {
    return GeneralModule
};

export const ROUTES: Routes = [
    { path: 'dashboard', component: DashboardComponent },
    { path: 'story/:id', loadChildren: loadChildrenStory },
    { path: 'general', loadChildren: loadChildrenGeneral },
    { path: 'extensions', component: ExtensionsComponent },
];

Rebolon on Dec 26, 2016

Is there a workaround for the ‘entry.split is not a function’ error? After weeks of trials and errors and various fixes and updates to angular-cli, I still cannot get it to produce separate bundles for loadChildren. Everything ends up in the main bundle. Using the above mentioned method with es6-promise-loader works but produces said error. Using b23.

achimha on Dec 20, 2016

Ok, I’ve got it working in “debug” (I meant non-AOT 😉 ) mode. The key is that you HAVE to restart the server (kill ng serve and start it again) for this change to be picked up. Just recompiling on the fly doesn’t help. I’ll play more with AOT tomorrow.

ctrl-brk on Nov 20, 2016