Angular2 RC5 forces one to move component imports to NgModule declaration - Why?

Question

It seems any import statement you previously made in your Components that were declared in the directives, pipes and providers part of the @Component() now must be moved to the @ngModule declaration.

Why is this?

I understand that it's to lessen boilerplate in the Components but this only makes sense for declarations that are reused multiple times in the application.

For directives, components, pipes or providers that are only used in one single component, it seems very unnecessary and will lead to heavy bloating of the @ngModules file.

In the link below, in the final step5 it states:

For RC5, you can leave your components, directives and pipes in the directives and pipes properties of your @Component metadata. In fact, we automatically hoist (add) them to the NgModule to which they belong.

This option is temporary for backward compatibility. It will be removed in the final release of Angular 2.0.

Get ahead of the game and start moving your component directives and pipes into module declarations as soon as possible. We intend to delete all deprecated class, methods, and properties in the next RC.

Source: RC4 to RC5 migration

Answer 1

Update 2

As I do more work with NgModule myself, I find that the real answer to this is what the docs call Feature Modules.

This is the idea that for subareas of the application that have declarations, etc. you are supposed to put each area into a sub-module, AKA feature module.

So, your components that have directives only used in them, and not used application wide, will not turn into a component + a module, where the module is about declarations and providers, and the component is just doing normal component work.

I'm not sure whether I like this for decorators, but I definitely like it for providers for example. Now it's easy to know where to look for providers of services when debugging service lifetime issues if you run into those.

One more thing I'm still not sure whether I like or not, is that feature modules do not inherit module imports from parent modules. This means you have to import BrowserModule, HttpModule, and FormsModule in every single feature module. I understand why (to be self-contained), but I hate the verbosity.

That said, you can wrap all common imports into a shared module, and now you have one thing only to import into your feature modules. That's the usage pattern suggested by ng2-translate for example, look here after "If you have multiple NgModules".

Update 1

The particular section of the design doc that answers this question is the section titled Deprecation (and sub-section Why inside it. Here's a direct link to that section.

Original Answer

The idea is that the AoT (Ahead of Time) compiler can take a module and compile all its dependencies in one go. It's also that within the same module, you don't have to redefine them in your component context repetitively.

Also the router is then able to use modules as boundaries for lazy-loading, since it can lazy load a module knowing the module declaration contains all its dependencies.

If you read the announcement and design document you'll get the idea better.