Error when Angular component defined in separate Bazel package from the NgModule about angular-bazel-example HOT 8 CLOSED

@pshields At the moment, the Module is the unit of compilation with Angular. The first party stuff that packages a bunch of components (Material) gathers small handfuls of closely related components into modules; this also seems to match the way components are most built and used in large apps, typically not one at a time but in small groups.

I can't speak for the future, whether some later re-factoring might make these ideas obsolete, but for the moment I don't think the design of Angular is aimed at the notion of having a bunch of free-floating components that you package up into modules at the point of use.

from angular-bazel-example.

ts_library doesn't produce Angular metadata outputs, so we lose any information about the decorators. The only outputs are .js and .d.ts and these are both lossy with respect to the analysis needed by the angular compiler.
At google, we just mechanically change any ts_library that depends on Angular into an ng_module. That's easy for us to do, because Angular has to appear in the deps. In open-source, you can depend on anything in node_modules without listing it in deps but we could still have a check that fails compilation of a ts_library if it sees an import {} from '@angular/*'

from angular-bazel-example.

Thanks Alex. There's a problem with turning the ts_library into an ng_module; if we do that, we get e.g. Cannot determine the module for class ComponentA errors on the child ng_module targets (example repro), since the components aren't declared by an Angular module at that point. In that example, the //src/foo_module/component_a:component_a ng_module contains only the component declaration for ComponentA. FooModule, which declares ComponentA, is declared in the parent directory foo_module's ng_module. This mirrors the original issue @webdevelopland ran into in #87. So is that a bug? Or is it impossible to define a component in one ng_module target and declare it as part of an Angular module in a separate ng_module target? That would seem to make it impossible to define per-component Bazel packages / BUILD rules, unless you give each component a corresponding NgModule that declares it.

from angular-bazel-example.

from angular-bazel-example.

We should do two things to close this:

• give an error when a ts_library uses an Angular decorator, it should have been an ng_module
• an ng_module rule without an @NgModule should error explaining that you can only compile one or more @NgModules, and need to re-organize your code so that every Bazel package has one

from angular-bazel-example.

Thanks Alex. I agree with those two AIs to make it easier for developers to catch this class of problem and learn how to fix it.

Longer-term, is there any chance of, say, an ng_component rule that could allow for independent compilation of a component without knowing its module? Or would it be possible to modify ts_library to preserve the information needed by the Angular compiler?

The developer experience of not being able to have per-component build packages seems suboptimal. Defining "leaf node" component packages, and hooking them up in a parent ng_module, is a pattern I'd often want to use---especially while there is a need for other per-component build rules such as sass_binary.

from angular-bazel-example.

Currently the NgModule holds some of the context the compiler needs to resolve things like selectors in the component it compiles.

One of the goals with Ivy is that compilation of a component is local - this would mean NgModule becomes optional and the constraint we're discussing will go away. Targetted for Angular v7.

from angular-bazel-example.

moved to angular/angular#32652

from angular-bazel-example.