Discussion: deprecate modules having single component exports (SCAM)

[chintankavathia]

Overview

We currently have lots of SCAM (single component and module) (~32)

Proposal

Deprecate modules which exports only single component/directive

Why

• Angular already recommends standalone
• When application import such module it adds up ~500 bytes in production build small but if 32 modules are imported becomes significant
• We have less files to maintain. less time to lint => faster pipeline (not so significantly but still)

[kfenner]

As with the introduction of schematics, I think we could even deprecate all the modules and offer migration scripts to get rid of them. WDYT?

[chintankavathia]

As with the introduction of schematics, I think we could even deprecate all the modules and offer migration scripts to get rid of them. WDYT?

Yes that would be even better. but migration scripts are only for existing code and some devs may not like importing every individual component while they implement new features especially when there are more than 2 things needed to be imported for one component and also in such cases they don't remember what all components/directives/services to be imported (shouldn't be a big problem as they can always refer our docs)

[spike-rabbit]

I am not really sure here. They do not really bother us. We should just not introduce new ones.

As far as I remember the angular migration also is capable of replacing 3rd party modules with respective component imports.
So we don't need to build anything in terms of schematic.

[timowolf]

We can deprecate, but still keep them in 49. remove in 50

[ljanner]

To me it seems reasonable to deprecate them if we have a working migration schematic (angular or custom).

Without it, working with deprecated modules and not having time to replace them manually due to project timelines gives an uneasy feeling as a consumer.

[kfenner]

We decided in the core-team-discussion that we should do this but deprecated it as part of the next major release (v49) so it gets the attention needed and we can properly explain this to the consumers. We should also directly describe how to do the migration with the schematics offered by Angular. This should minimize the number of people attempting to do this manually or even getting confused about the deprecation of these modules without understanding that they should just migrate to standalone.