Cyclic Dependency Problems about rushstack HOT 3 CLOSED

Hi @fuocor,

One thing that is important to note about cyclic dependencies is that once you mark a dependency as being "cyclic", rush will not locally link the dependency and instead it will attempt to install an acceptable version via NPM.

So in your example, when projb marks proja as being cyclic, Rush will attempt to install proja from the registry. If you think about this, it makes sense: Rush needs to build the projects in the right order, and a cycle makes it impossible to know which project to build first. We break the cycle by effectively allowing one of the packages to depend on the previously published version of its dependency.

That being said, we definitely advise against using cyclic dependencies. We only use them in a handful of cases, such as in the web-build-tools repo where we want to build gulp-core-build, node-library-build, etc using the previous iteration of node-library-build.

Generally speaking, it is fairly strange to have cyclic dependencies. May I ask what the intended purpose of the packages are (e.g. is proja a library and projb & projc applications)? We would be able to give an alternate suggestion around your code structure to ameliorate this problem.

from rushstack.

thanks for the response,

I noticed that it was being used in the ui-fabric-react codebase, and I thought I'd use it to manage some dependency injection requirements I have.
I already moved on to a more traditional consumer/provider approach with an abstract intermediary referenced by both (similar lo localization of resources).

The consumer is a composite made up of an arbitrary number of provider components. The problem I have is the sheer number of specialized providers (~3000 and growing). The configuration (JSON) is read at runtime, and flows through factories assembling the providers. If I pull everything in to resolve the configuration it costs me 4-5MB of minified code, which is a nightmare to compile, By having a cyclic dependency I could have defined the consumer interface implemented by the providers and rolled together when bundling.

I was hoping that perhaps you guys figured out a way to resolve exports prior to evaluating imports...

For the time being I bind the providers at runtime as external modules.

from rushstack.

@nickpape

rush will not locally link the dependency and instead it will attempt to install an acceptable version via NPM.

I have circular dependencies, as my projects are dog fooding each other.

As an example: I am making a library, and I'm making a documentation tool for documenting the library (or other libraries), and the documentation tool consumes said library in its implementation while the library depends on the doc tool for generation of documentation.

I think #1721 would be convenient to have in cases where the links are skipped, so then we can manually override and get back to work.

from rushstack.