Improve library compiler cyclic dependency detector (NG3003)

Feature Request

When porting my library to v12 I’ve tried compiling with the partial-ivy recommended mode. This resulted in a never ending bombardment of NG3003 errors due to cyclic dependencies.

The current library compilation is very strict which results in

• Poor library developer experience
• Workaround manoeuvres to make it compile resulting in less code readability which makes it more difficult for devs to enter into open source projects.

First, i’ll say that such a breaking change, from warning to error should have been introduces gradually.
These are not pure cyclic dependencies, they don’t result in a null reference since the symbols are used later.

I understand that it compromises efficient tree shaking. Ok, for hard-references throw the error, but why does it also throw for soft-references, symbols used only for type annotation on properties etc… those that are not Input, Output, DI… it will throw for those soft references as well.

What’s more confusing is that type imports is also not supported… Even with import type { X } from './y' it will complain about X being a cyclic dependency.

I almost ran out of trick until I found something which works:

// tokens.ts
export type X = import('./y').X;

And now I can use that type without issues.

This limitation should improve as it forces the developer to write funky code which he wouldn’t write otherwise. The docs recommend bad practices to workaround this as well.

I understand the reason behind forcing authors to build efficient tree-shakable libraries, although allowing to control the volume of this restriction would be nice.

Moreover, soft-references and surely type imports are not cyclic by all means and are not used for metadata by angular so they should not throw.

I’m now required to refactor a 4 year old repo with lot’s of code, frustrating.

Thanks 😃

[JoostK]

This is of-course voodoo magic so I moved to hard referenced registration.

Yep, that sounds like the correct approach to me 👍

Anyways, you mentioned:

There are no plans to revisit this at the moment, though, but your feedback is valuable information.

Are you referring to the support of import types?

Nope, the type-only import should be addressed. I meant to indicate that there are no plans to support circular dependencies.

Some of it will leak to public API implementations, so I think doing that sooner is better or at least provide some guidance with an exit strategy later on.

I mean, import('./x').X will work but it’s a dev nightmare in terms of experience.

Agreed.

[angular-automatic-lock-bot[bot]]

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.}