Initial Angular modules design, most of it is still valid. Especially the reasoning and benefits of Angular modules. See this design doc.
Discussion about problematic previous semantics of module directives and pipes, see this design doc.

Overview

The @NgModule is needed to:

Compile time: Configuration of the template compiler.

Provide compilation context (which directives/pipes are visible in a directive) for the template compiler. (Visibility of components, directives, pipes, and eventually schema)
Provide a way to have ambient directives (such an ngIf, ngFor, ...) in the way which is scoped to a set of directives (such as Material Design, Ionic, Forms, etc)
Provide a mental model for reusable libraries: (such as Material Design, Ionic, Forms, etc)

Runtime: Defines how to create an injector using the providers defined in the module and modules it recursively imports.

Configuration (and composition) of the injector through providers.
Eager initialization.

@NgModule

class NgModule {

declarations: Array<ComponentType | DirectiveType | PipeType>;

imports: Array<ModuleType | ModuleWithProviders>;

exports: Array<ComponentType | DirectiveType | PipeType | ModuleType>;

providers: Array<Providers | Array<any> >;

entryComponents: Array<ComponentType>;

schemas: Array<any>;

}

An NgModule provides a compilation environment for components it contains. In practice NgModule defines which set of components, directives, and pipes are available to the template of the components owned by the module.

Each component (directive or pipe) must be owned by exactly one NgModule.

A component is owned by an NgModule if it is listed in its declarations property.

declarations

List of components, directives, and pipes which belong to this module. All declarations listed here are visible in this module without any explicit imports.

Component: Compile this component with the rules of this module.
Directive/Pipes: While not strictly needed to be listed here for compilation (because there are no templates and hence to factories created) listing these directives/pipes here will ensure that the right set of providers are available to the directives/pipes.

imports

Imports allows you make exported declarations from another module visible within the templates of components that are part of the current module. Importing a module does not automatically re-export the imported module's exports.

exports

List of all declarations which should be available to other modules, which import this module. A module in this list will have all of its exports re-exported using current module.

providers

A list of providers to configure the injector when this module is imported. Providers are always imported / merged from other modules.

entryComponents

A list of components for which ComponentFactory should be generated. ComponentFactory is used for dynamically loading components (and bootstrapping). The components listed here do not have to be declared in the current module (but have to be declared in some module and then imported into this module.)

schemas

PRE FINAL:

If omitted will only allow DOM elements schema (throw on unrecognized DOM elements and properties). If pointing to CUSTOM_ELEMENTS then the compiler will allow any property on kebab cased elements. (useful when working with web-components).

NOTE: this feature is needed to throw useful error messages during migration period. Without it a component which will be stolen (referred to in @Component.directives without havinig appropriate module imported) by a module would silently not include directives.

POST FINAL:

Allow definition a schema for custom elements. Will allow configuration of which custom elements are allowed, what are their properties, and their events.

Examples

Module Declaration:

Assume one has a component as declared here:

import {Component} from '@angular/core';

@Component({

template: `

<button md-button>material buttons are allowed</button>

<div *ngIf="true">core directives are present.</div>

})

class MyAppRootComponent {

}

The above application will need a main module definition such as here:

import {NgModule, ApplicationRef} from '@angular/core';

import {CommonModule} from '@angular/common';

import {FormsModule} from '@angular/forms';

import {MaterialModule} from '@angular2-material/module';

import {MyAppRootComponent} from './my-app-root-component';

@NgModule({

declarations: [MyAppRootComponent],

imports: [BrowserModule, CommonModule, FormsModule, MaterialModule],

entryComponents: [MyAppRootComponent]

})

class MyApplicationModule {

constructor(appRef: ApplicationRef) {

appRef.bootstrap(MyAppRootComponent);

}

Notice that the main module imports CommonModule, FormsModule, MaterialModule. This allows the MyAppRootComponent to implicitly use md-button, ngModel, and ngIf without any additional imports on the @Component level.

Dynamic bootstrap:

import {MyApplicationModule} from './my-application-module';

import {platformBrowserDynamic} from '@angular/browser-platform-dynamic';

platformBrowserDynamic().bootstrapModule(MyApplicationModule);

In this example the application module is bootstrap using in the browser compiler.

Offline-compile bootstrap:

import {MyApplicationModuleFactory} from './my-application-module.ngfactory';

import {platformBrowser} from '@angular/browser-platform';

platformBrowser().bootstrapModuleFactory(MyApplicationModuleFactory);

In this example the application is bootstrapped using offline compilation. The difference is that we need to import the MyApplicationModuleFactory from a offline compiled / generated file and then bootstrap it. Unlike bootstrapModule the bootstrapModuleFactory is synchronous.

Legacy bootstrap:

import {bootstrap} from '@angular/browser-platform-dynamic';

import {MyAppRootComponent} from './my-app-root-component';

import {FormsModule} from '@angular/forms';

import {MaterialModule} from '@angular2-material/module';

bootstrap(MyAppRootComponent, {imports: [FormsModule, MaterialModule]});

The above bootstrap does not depend on a module. Rather the module is created implicitly in the background. Also notice that there is no need for the CommonModule, as that one is automatically included to match the old PLATFORM_DIRECTIVES behavior.

Lazy Loading Modules

Imports have dual purpose. They provide context to the compiler and at runtime they affect how injector provisions instances. Applications import a module into its root module and optionally the module can be imported into a child / lazy loaded modules.

Lazy loading adds a particular constraint on the module. This is because a third-party module (such as ionic) has to be imported in both the root module as well as the lazy loaded module (this is needed to load the directives). However only the root module should configure the ionic services. By supporting both the IonicModule as well as the IonicModule.with syntax we can satisfy both of the constraints. (Module.with() should be added to our style guide.)

Assume a third party Module such as:

@NgModule({

declarations: IONIC_DIRECTIVES,

imports: [ BrowserModule ],

exports: [ IONIC_DIRECTIVES, BrowserModule ]

})

class IonicModule {

constructor(@Optional() @SkipSelf() parent: IonicModule,

appRef: ApplicationRef) {

if (!parent) {

// make sure to only bootstrap when the module is root module.

// Don't run this in lazy loaded component.

appRef.bootstrap(IonicAppRoot);

}

static forRoot(mainComponent: Component, config: any) {

return {

module: IonicModule,

providers: [

{provide: IONIC_CONFIG, useValue: config},

{provide: IONIC_MAIN_COM, useValue: mainComponent},

{provide: ANALYZE_FOR_PRECOMPILE, useValue: mainComponent,

multi: true},

OtherIonicService,

...

]

};

}

Can then be used for root module to configure both the module exports as well as the providers as:

@NgModule({

declarations: [MyRootComponent],

imports: [

IonicModule.forRoot(...ionic_config...),

FirebaseModule.forRoot(...firebase_config...)

]

})

class MyAppModule {}

And for lazy loading module only load the module exports (not the providers) as:

@NgModule({

declarations: [ LazyLoadedComponent ],

imports: [ IonicModule ]

})

class MyLazyAppModule {}

Example with router

class RouterModule {

forRoot(routes: any) {

// add ANALYZE_WITH_PRECOMPILE provider

// + Router provider

}

forChild(routes: any) {

// just add ANALYZE_WITH_PRECOMPILE provider

}

Lifecycle

A module including its imported and exported modules are created eagerly when NgModuleFactory.create is called. For some use cases, this is not enough and so we are exploring a more in depth lifecycle hooks in @NgModule Lifecycle Hooks.

Deprecation

The ability to import directives and pipes into components will be deprecated. This means that after deprecation the following properties will be removed: @Component.directives and @Component.pipes.

Why

Keeping @Component.directives/pipes causes the following issues:

Two Scopes

It creates two scopes: module scope and component scoped. The module scoped is very similar to how ES6 modules work. As a result, it is easy to explain to the user. We have to have it for dev ergonomics. The component scope is unique and harder to explain.

Breaks ES6 Mental Model

Having the component scope breaks the ES6 mental model. In ES6 to use a token you have to import it from a module. Tokens don't just appear out of nowhere. It is easy to explain that to use a material component you need to import the right module. Because that's what you would do with ES6.

Nobody Will Use It

Modules create small-enough scope to avoid collisions, and they are significantly more ergonomic. Because using modules is more ergonomic, the Component.directives option will not be used in practice. As a new Angular user I have to use modules to get my forms and common directives, so it is natural for me to add my own directives there.

Transition Period

During transition period the behavior of @Component.directives and @Component.pipes will change slightly by making more things available to component template then before, but we don't expect the change to result in changes to the application behavior.

Note: This section will discuss @Component.directives behavior, but same rules are applied to @Component.pipes.

During the transition it is possible to have components which are not explicitly declared in the @NgModule.declarations field to mimic the old behavior. The situation can arise when a component references another component through @Component.directives. In such a case the referenced component will be included in the same module's declarations as the referencing component.

Assume this old component declaration.

@Component({})

class MyComponent {}

@Component({

directives: [ MyComponent ] // deprecated behavior

})

class MyAppRootComponent {}

To migrate to modules the developer will have to declare main module like so:

@NgModule({

declarations: [ MyAppRootComponent ], // Include root component only.

module: [ CommonModule ]

})

class MyAppModule {}

The above will cause MyAppRootComponent to be part of the MyAppModule because it is referenced in the declarations property. The MyComponent is referenced from MyAppRootComponent therefore it will also be implicitly included in the MyAppModule's declarations property. We only include the directives found via @Component.directives into the declarations of the module if none of the included modules already contains it in their declarations property. The end result is equivalent to:

@Component({})

class MyComponent {}

@Component({})

class MyAppRootComponent {}

@NgModule({

declarations: [ MyAppRootComponent, MyComponent ],

module: [CommonModule]

})

class MyAppModule {}

The resulting implicit changes are equivalent to what the developer will have to do explicitly during a proper migration.

There are two possible failure modes:

Seeing too much:

One important thing to notice is that it is possible that by hoisting the components from the @Component.directives to @NgModule.declarations that some components will have more components / directives available to them after the change. We don't think that this will result in a real world issues. As it is unlikely that:

two components will have the same selector. If they do the resulting compilation will fail as only one component is allowed per element.
two directives with the same selector. (is a more likely, but we still don't expect it to happen in real world). Unfortunately if it does, there will be no error.

Accidental Component Kidnapping

Assume this code:

@Component({

directives: [ MdButton ]

})

class MyAppRootComponent {}

@NgModule({

declarations: [ MyAppRootComponent ],

module: [ CommonModule ]

})

class MyAppModule {}

In the above example the MyAppRootComponent imports MdButton, but the MyAppModule forgets to import MaterialDesignModule. The result is an incorrect assumption that the MdButton is a free floating component and that it should be included in the MyAppModule's declarations property, resulting in MdButton being compiled by MyAppModule rules rather then MaterialDesignModule. To better understand see this implicit change:

@Component({})

class MyAppRootComponent {}

@NgModule({

declarations: [ MyAppRootComponent, MdButton ],

module: [ CommonModule ]

})

class MyAppModule {}

The problematic part is because the component is compiled using different module it is possible that many of its needed imports are missing, resulting in incorrect behavior.

The correct behavior should have been:

@Component({})

class MyAppRootComponent {}

@NgModule({

declarations: [ MyAppRootComponent],

imports: [ MaterialDesignModule ]

module: [ CommonModule ]

})

class MyAppModule {}

Kidnaping behavior is easy to achieve. To mitigate this we will make custom-elements support opt in using the schema property. By default the compilation mode will only allow DOM elements or angular components and properties. In this way if a component is accidentally stolen by a module the extraneous element names or attribute names will be flagged as invalid by the schema. If the schema passes, the component is still stolen, but will most likely behave same as all of the directives are accounted for. (The component could inject missing providers from its true module but that will be discovered at runtime.)

If the developer is using web-components they will have to explicitly opt-into it, and then they run a higher risk of component theft as describe above. We think that there are only few applications which rely on web-components, and so only few applications will run the risk of component theft.

Replacing platform directives with modules

The current platform directives (configured via providers for PLATFORM_DIRECTIVES) will be deprecated and removed earlier than @Component.directives. The replacement is to import the correct module, e.g. FormsModule or RouterModule. The CommonModule that includes ngIf, ... is automatically included in the BrowserModule which is automatically used for bootstrap.

Rejected Ideas

Pointer from @Component to @NgModule

A reasonable question would be why is there no pointer from @Component to @NgModule?

Benefits of pointer from @Component to @NgModule:

By having an explicit point, it would be clear that a component can only be a member of exactly one module.
There would be no component kidnap issue as discussed here.
One would be creating a declarations at the time of actually declaring the component.

Organizational reasons against pointer from @Component to @NgModule:

NgModule can keep all of the list together: declarations, imports, exports.
Easier to move group of components between modules.
Parent listing children is an easier relationship to manage than children listing parents.

Technical reasons against pointer from @Component to @NgModule:

Module needs to have pointers to Components (when listing entryComponents, exports, imports). Having a pointer from component to module would mean that there would be a circular dependency. When ES6 module loader would resolve imports it would have to choose which file to load first. File loaded first would then have to wrap the pointer to the other file in forwardRef. If the order of file loading would change (which is possible as the order of circular deps is no guaranteed) then the other file would have to wrap it pointers in forwardRef.

After looking at the benefits cost, we decided to opt to keep all of the information in the @NgModule.

Testing with @NgModules

See separate document. Initial implementation is in this PR.

Simplifying Bootstrap

With the apis as proposed above even the simplest app that uses NgModules requires developers to know about ApplicationRef and its bootstrap method. This creates a barrier for entry and forces us to document many advanced concepts early in the developer's journey.

One solution to this problem was to preserve the existing "bootstrap(MyComponent, {/*implicit module def */}" method (also called bootstrap junior) that could be used for these simple cases. The downside is that this api is only useful for plunkers and small apps and can't be used for offline compilation cases, forcing the developer to learn a very different way to bootstrap their app when they get more serious.

Alternative approach to that would be to allow declarative specification of the component to bootstrap within the module metadata:

// app.component.ts

@Component({ ... })

class AppComponent {}

// app.module.ts

@NgModule({

imports: [BrowserModule]

declarations: [AppComponent],

bootstrap: [AppComponent]

})

class AppModule {}

// main.ts

if (prod) enableProdMode();

platformBrowserDynamic().bootstrapModule(AppModule);

// main-offline.ts

if (prod) enableProdMode();

platformBrowser().bootstrapFactory(AppModuleNgFactory);

The "bootstrap" property of NgModuleMetadata would cause the codegen to generate module factory that would be comparable to this manual bootstrap:

// app.component.ts

@NgModule({

imports: [BrowserModule]

declarations: [AppComponent],

})

class AppModule {

ngDoBootstrap(applicationRef: ApplicationRef) {

applicationRef.bootstrap(AppComponent);

}

With this change we would make the bootstrap simple enough that we could drop the "bootstrap junior" api and have a single way to bootstrap the app for simple and advanced usecases.

Properties:

This is an extension of the ngBootstrap proposal discussed with Tobias earlier - it just adds a declarative way of bootstrapping the app.
By specifying a component in the bootstrap array it automatically becomes an entryComponent, so there is no need to list it in both bootstrap and entryComponents array
A module can either have "bootstrap" metadata property or ngDoBootstrap method but not both.
It should be possible to specify multiple components to bootstrap (hence the array type) so that we can simplify the multi-root-component use-cases.

Issues

Outstanding

HOT STATUS:

Hans: g3 regression due to latest in NgModules. Need to untangle this before we can continue with the sync. Caretaker requests freeze on master so we can complete a sync and validate RC5. Changes needed by g3 could then be directly merged. Current ETA on unblocking google3 is potentially several days of work. 130 TAP breakages.
Ionic: Metadata extractor fixed as of this morning, need Ionic validation. Josh confirms metadata fixed. Still has one problem for offline, gated on Adam getting back in the office Wednesday AM.
Stephen: Ames is blocked on AngularFire. Need to update to Rob's local build to demo that this is working.
Minimal lifecycle implementation for RC5 is in.

ENDORSED:

Hans: CLI endorses RC5. This will only work for WebPack. However, CLI cannot issue a new release until Mobile is unblocked by Universal support for NgModules. (Not RC5-blocking.)
Ward: Finish the testing chapter and the NgModules docs and update for new solution to get rid of "bootstrap junior". Code for docs now work, focusing on text. Not RC-5 blocking. (ok if ES5 slips. Ok if NgUpgrade doc pins to RC4)
Misko: Periscope now runs in offline mode, using a local build of AngularFire. Periscope endorses RC5.
Jeremy: Material is running on RC5. There is a bug in asynctest zone that seems to pre-date this work and is edge casey. Material endorses RC5.

---------------

THE LIST OF EVERYTHING:

Testing

Changes have landed in master via PR10355
Ward to update tests in docs to latest.

Material Validation

[Close to done, pending bugs] Jeremy is close to done? Needs to create NgModules that work with current master. [ETA Thursday afternoon]
Demo site with all components works, all tests pass, but one apparent race condition is causing a non-failing async exception to thrown while tests are running. The error is that initTestModule hasn't been called. Need some help to debug this. Have not tried to offline compile an app.
Had everything working, but updating to the new TestBed APIs broke tests again (all templates are being requested with the wrong URLs now). Should hopefully be able to resolve today (likely something in material itself).
Material release will be needed to support external users who depend on Material alpha + NgModules. This will be a known issue documented in RC5 announce if we can't ship a Material Release on NgModules at the same time.
Per-sha releases for Material would be nice to have. Not blocking but desirable.

Must validate that an app can work in static mode.

Validated with Periscope.
AngularFire is working with offline compiler, via local pre-release build.
Periscope and Ames should be able to work in static mode.

Ionic Validation [Adam]

Dynamic mode working. Blocked on static mode working.
Need to rewrite providers - trying to get through ngc errors now.
Seeing ng factory files being built; surprised this is happening. Needs help. [Igor + someone else, maybe Alex]

Docs Validation (Status GREEN)

Need a branch to update docs to use the new NgModules. Ready to start. Ward to scope out effort. Angular.io branch w/ RC5-ready docs is docs-rc5-min
Ward to check that current master works with existing samples. [today?].
All samples (TS/JS) minimally converted by Filipe (mostly), Brandon, and Ward. They all pass E2E tests except

Deprecated Forms (works only with RC4 … and will not move forward)
Deprecated Router (works only with RC4 … and will not move forward)
NgUpgrade (working except for unit tests awaiting NgUpgrade support)
The NgUpgrade Chapter includes unit tests that require test bed functionality that no longer exists in RC5. Our plan is to disable those tests in the sample and alert the reader that we’ll be updating those parts very soon. And we will … after RC5 lands and we have the new TestBed.

Update all chapters to conform to the way we want them to look with NgModules.
Author team is divvying up the chapters and cookbooks, Plan to complete update by Monday Aug 8th
Ward to complete Testing Chapter which explains and confirms the most current TestBed (which is still in development). Confirmation of the new testbed is potentially blocking; the completed chapter is not.
All Testing Chapter tests revised and working with the new TestBed (see “Testbed issues”). Can commence chapter text after NgModules Chapter.
TestBed issues: encountered a few gotchas that would be nice to clear before RC5. See “NgModules and Testing”
Add “NgModules” chapter: Ward’s draft expected EOD Aug 1
Dgeni API doc generation templates should be updated to reflect module ownership. (When do you import BrowserModule? When do you import Common?) [Ward and Igor to discuss]
API doc generation currently errors. Need help from Pete to fix?

G3 sync Validation

Hans thinks we will catch up by EOD Monday hopefully.

NOT Blocking RC5

Better error message when calling a function from the annotation. Current error message does not give me file/line/column where the problem comes from.
XHR should be renamed into ResourceLoader [Vikram, not blocking]
Better Error message for Directive queries (jelbourn): @ViewChild, @ContentChild, etc. are silently set to either undefined (child) or an empty QueryList (children) if the directive being queried for is not in the module. This should really throw an error. (Jeremy says, nice to fix bc people will run into this while converting, but not RC5 blocking)
Can we improve the problem with silent bootstrap failure because developers forgot to boostrap the app component from the module constructor.
Finish Testing design doc and add summary to this doc
Ames Validation [Stephen]

Everything works except:

Material on NgModules because we'd need a Material release on top of RC5.
NGC is blocked on AngularFire & material. [RobW has a fix for angularfire to try] May not be Rc5 blocking.

Periscope Validation [Misko]

Everything is working except AngularFire integration in static mode.

2 bugs in Tour of Heros from Ward in this plunker

[PR#10348] The <hero-search> in DashboardComponent is missing. The tag is in the DOM, The component is not.

This is because DashboardComponent is auto declared because it was used via entryComponents, and we have a bug there that does not recurse into @Component.directives in this case

[PR#10383] Lists don't refresh when press "Back" from hero detail

Seems unrelated to ngModules, who can investigate

Resolved

Tobias: Has landed bootstrap fix (https://github.com/angular/angular/pull/10383) and looking at lifecycle which IS NOW RC5 blocking. Hopes to finish lifecycle by tomorrow.
Better Errors -- done! Going in.

[Misko PR#10398] Can we improve the No Provider for ApplicationRef error message - we could catch it when boostrapping module and suggest that the developer forgot to add an angular module that defines it, most likely BrowserModule (blocks RC5)
[Misko PR#10398] if we have an template like: <my-component [someProp]=bar></> and this template is compiled in a context where there is a MyComponent with the right selector but the component doesn't have someProp, we throw the same error that Ward posted and suggest that people augment the schema. This is wrong, we know that this is an angular component that doesn't have someProp as @Input so we should throw different error message (blocks RC5)

[PR#10346] Angular components fails DOM schema check if it contains dashes. See plunker and details.

The line <my-if-child-comp [(value)]="parentValue"> correctly uses MyIfChildComponent, which was declared correctly in the module and also has value input.
The problem is that this line also triggers the InputValueBinderDirective, which has a host binding for value. So far, host bindings always write to the DOM directly, and therefore we get an error saying that value is an invalid property on the DOM element <my-if-child-cmp>, which is correct.
In this case, InputValueBinderDirective was never meant to apply here (only to input elements), but because we have modules now it applies as well.
We could change the semantics of host to be able to write to the underlying component, but that is not trivial

can a directive write to an input of another directive via host? Then there could be cycles that we need to detect. [Misko: I don't think we should do this]
need to be careful about the order of the bindings then

[Chuck] Given a static symbol such as MyComponent.SYMBOL, it can not be used in @NgModule as metadata collector returns an error. Issue #10332, PR #10334, Committed to master.

class MyComponent {

static final SYMBOL = new OpaqueSymbol(...);

}

@NgModule({

providers: [{provide: MyComponent.SYMBOL, useValue: 123}]

})

class MyModule{}

WIP: @angular/http does not have HttpModule. PR#10329 [RobW is working on this, Igor to review. ETA today.]
RC4 Deprecation Strategy - Router Declarations - Applications built targeting RC4 (using bootstrap(RootAppComponent, []) and the implicit DynamicModule fails when upgrading to RC5 because the routed components are added as entryComponents, but not declarations .
Unhandled Promise rejection: Error: NgModule DynamicModule uses RoutedComponent via "entryComponents" but it was neither declared nor imported!
Treat some-element as unknown element so that [class] bindings work. PR#10300
browserDynamicTestingPlatform is exported as deprecated but this api has never been released so we should just remove it.
@HostListener not appropriately generating code: https://github.com/angular/angular/issues/10308
Provides declared by modules cannot be overridden. See here: https://github.com/angular/angular/issues/10313
Unhelpful error message masking deprecation issue: "Error: Type DefaultValueAccessor is part of the declarations of 2 modules: InternalFormsSharedModule and PeriscopeModule!"
It is unclear how InternalFormsSharedModule got loaded since it is not reference from PeriscopeModule. A better error message should show a path of which modules imported which other module etc.. In this case the issue is that PeriscopeModule compiles PeriscopeApp which uses MdInput which uses DefaultValueAccessor (That is also imported from the InternalFormsSharedModule). Because the imports of PeriscopeApp => MdInput => DefaultValueAccessor are done through @Componet.directives, this should be allowed. This prevents proper deprecation story.
Clone this then npm install and ngc -p src to repro the problem.

ngc generates code for all files that are transitively imported from the files section in the tsconfig.json. This includes libraries like @angular/forms or material that only ship .d.ts files with .metadata.json files.

This is because we said that libraries should not ship their generated code, i.e. every user will regenerate the code of libraries.

In this case, ngc compiles @angular/forms as well, including the InternalFormsSharedModule. However, as persicopes's AppModule is not importing the FormsModule (and with it the InternalFormsSharedModule), ngc will compile persicope's AppModule and the InternalFormsSharedModule individually, without connecting them.

The fix for this problem is that the application needs to import the FormsModule to work. Then our metadata analysis detects that the directive was already declared by the FormsModule and would not redeclare it in PersicopeModule.

A solution that would not work: Add an option like genExclude to ngc and specify that it should not compile code for @angular/*. This is ok for @angular as it does not contain components, i.e. we only need metadata from it.

However, this won't work if a library like material starts to ship a module. Here, a user using rc.4 will see the same problem as with the FormsModule in periscope, but we cannot exclude material from codegen as it contains components that need to be compiled.

Regarding deprecation:
This is only a problem in offline compile. As offline compile users already have to create a root ng module with rc.5 (which they did not have in rc.4), telling them to also import the corresponding modules of libraries that they use into this root ng module is probably ok.