Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(aot): Use the proper path when statically analyzing lazy routes. #2992

Merged
merged 1 commit into from
Nov 3, 2016

Conversation

hansl
Copy link
Contributor

@hansl hansl commented Nov 3, 2016

Before, we were using paths relative to base at all time, but these
might not be the paths we get in System.import(), therefore we have to
keep the relative path.

BREAKING CHANGES: Using relative paths might lead to path clashing. We
now properly output an error in this case.

Fixes #2452
Fixes #2735
Fixes #2900

@hansl hansl force-pushed the aot-lazy-fix branch 2 times, most recently from 2f598e1 to 4ef9f1c Compare November 3, 2016 00:49
@hansl hansl force-pushed the aot-lazy-fix branch 4 times, most recently from 7acdbc3 to 3739374 Compare November 3, 2016 01:47
@Meligy
Copy link
Contributor

Meligy commented Nov 3, 2016

I noticed that I can have a lazy loaded module routed using relative path in the main app routes file, but if the lazy loaded module itself wanted to lazy load another module, it can only do it using a src relative path, not relative to the file where the route is defined.

Like:

In src/app/app-routing.module.ts, this works:

  {
    path: 'lazy',
    loadChildren: './lazy/lazy.module#LazyModule'
  }

While in src/app/lazy/lazy-routing.module.ts, only this works:

  {
    path: 'deep',
    // Loading by relative path didn't seem to work here
    //     loadChildren: './deep/deep.module#DeepModule'
    // have to:
    loadChildren: 'app/lazy/deep/deep.module#DeepModule'
  }

Is this what the PR fixes?

@Meligy
Copy link
Contributor

Meligy commented Nov 3, 2016

@hansl
Copy link
Contributor Author

hansl commented Nov 3, 2016

Yes it fixes #2452 and #2735

@hansl hansl force-pushed the aot-lazy-fix branch 4 times, most recently from f82d568 to 51e87ae Compare November 3, 2016 03:13
@naveedahmed1
Copy link

naveedahmed1 commented Nov 3, 2016

So, should we expect lazy loading to work properly with AoT in next release? Even for large project (without Heep Errors angular/angular#12184)?

Before, we were using paths relative to base at all time, but these
might not be the paths we get in System.import(), therefore we have to
keep the relative path.

Also fix e2e tests.

BREAKING CHANGES: Using relative paths might lead to path clashing. We
now properly output an error in this case.

Fixes angular#2452
Fixes angular#2735
Fixes angular#2900
@unsafecode
Copy link

I noticed a new hidden release of @ngtools/webpack (1.1.5) on npm, but it seems not be working yet (it breaks on an undefined Promise.then()).

It there a workaround in the meanwhile to make lazy module routes to work?

@Meligy
Copy link
Contributor

Meligy commented Nov 11, 2016

@unsafecode the temporary workaround depends on what your problem is.

If it's lazy loading and AoT, you might have to pause using AoT.

If it's lazy loading at all, for example going from a lazy-loaded module (call it lazy) to another lazy-loaded module (call it deep), you can change the loadChildren path to start with app instead of ./ or ../. For example from './deep/deep.module#DeepModule' to 'app/lazy/deep/deep.module#DeepModule'.

Example: here: https://github.com/Meligy/routing-angular-cli/blob/deep-lazy-loading/src/app/lazy/lazy-routing.module.ts#L14

If it's lazy loading at all, that should actually be working in the current release (beta.19-3), and it has been working for a while.

@unsafecode
Copy link

@Meligy First one - I need lazy routes to work with AoT, much like how this repo offers https://github.com/antonybudianto/angular-webpack-starter

Note: there's actually a bug in the build, that stucks at 95% even after emitting files, but it works.

@Meligy
Copy link
Contributor

Meligy commented Nov 11, 2016

Note: there's actually a bug in the build, that stucks at 95% even after emitting files, but it works.

I know :(

I have seen it intermittently on a Windows machine that has an anti-virus I cannot disable. It seems when I do several file changes saved individually (generally due to VS Code not having a nice default "Save All" keyboard key binding), it tends to hang at 92% or 94% or 96% until I save another file or restart it. Since it's very intermittent and the machines I have to test on aren't ideal, I was not able to open a proper github issue.

Anyway, back to main problem...

I'm afraid AoT doesn't work with lazy loading at the moment. If you choose to continue with the CLI, you'll have to stop building with --aot, and check when the next release is out, hope for the best, and if it doesn't work, raise the issue again.

@harilalinapp
Copy link

#3141

I am facing the same issue. Already updated to the latest one (19-3) but no luck .

@harilalinapp
Copy link

harilalinapp commented Nov 16, 2016

After upgrading to : 1.0.0-beta.20-4 running 'ng serve --aot` shows another error
#0% compilingcompiler.AnimationParser is not a constructor
TypeError: compiler.AnimationParser is not a constructor
at Function.CodeGenerator.create (/Users/iminar/Dev/angular/modules/@angular/compiler-cli/src/codegen.ts:141:9)
at AotPlugin._make (/home/harilal/works/project/node_modules/@ngtools/webpack/src/plugin.js:189:54)
at Compiler. (/home/harilal/works/project/node_modules/@ngtools/webpack/src/plugin.js:157:75)
at Compiler.applyPluginsParallel (/home/harilal/works/project/node_modules/tapable/lib/Tapable.js:156:14)
at Compiler. (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:463:8)
at Compiler.applyPluginsAsync (/home/harilal/works/project/node_modules/tapable/lib/Tapable.js:73:70)
at Compiler.compile (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:456:7)
at Watching. (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:46:17)
at next (/home/harilal/works/project/node_modules/tapable/lib/Tapable.js:81:11)
at Compiler.invalidAsyncPlugin (/home/harilal/works/project/node_modules/webpack-dev-middleware/middleware.js:119:3)
at next (/home/harilal/works/project/node_modules/tapable/lib/Tapable.js:83:14)
at Compiler. (/home/harilal/works/project/node_modules/webpack/lib/CachePlugin.js:31:4)
at Compiler.applyPluginsAsync (/home/harilal/works/project/node_modules/tapable/lib/Tapable.js:85:13)
at Watching._go (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:44:16)
at Watching. (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:36:8)
at Compiler.readRecords (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:367:10)
at new Watching (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:33:16)
at Compiler.watch (/home/harilal/works/project/node_modules/webpack/lib/Compiler.js:204:17)
at module.exports (/home/harilal/works/project/node_modules/webpack-dev-middleware/middleware.js:146:27)
at new Server (/home/harilal/works/project/node_modules/webpack-dev-server/lib/Server.js:43:20)
at Class.run (/home/harilal/works/project/node_modules/angular-cli/tasks/serve-webpack.js:74:22)
at /home/harilal/works/project/node_modules/angular-cli/commands/serve.js:92:26
at process._tickCallback (internal/process/next_tick.js:103:7)

@maxime1992
Copy link
Contributor

maxime1992 commented Nov 24, 2016

Just for information, AOT is now working with lazy loaded modules (in angular-cli 1.0.0-beta.21) ! See #2452

@unsafecode
Copy link

HTH, I set up a demo repo to summarize how to make lazy routes work with @ngtools/webpack

https://github.com/unsafecode/ng2-aot

MRHarrison pushed a commit to MRHarrison/angular-cli that referenced this pull request Feb 9, 2017
…ngular#2992)

Before, we were using paths relative to base at all time, but these
might not be the paths we get in System.import(), therefore we have to
keep the relative path.

Also fix e2e tests.

BREAKING CHANGES: Using relative paths might lead to path clashing. We
now properly output an error in this case.

Fixes angular#2452
Fixes angular#2735
Fixes angular#2900
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
8 participants