Rule suggestion: Forbid cyclic dependencies

[dtinth]

I looked in the Issues board for standard and eslint-config-standard project but did not find anything related to this, so I decided to start a new issue.

While circular dependencies are useful in some cases, based on my experience, it more often than not led to very tightly coupled modules, which are very painful to refactor. In my opinion, it would be a great idea if dependency cycles could be prevented from the start.

Moreover, in a large project with 1,000’s of files and multiple developers, without always checking, it’s easy even for very experienced programmers to inadvertently create a dependency cycle, leading to errors such as “MyModule.myFunction is not a function,” caused by MyModule being partially executed due to being involved in a dependency cycle.

Prior art

• Go language does not support cyclic dependencies at all.

  The lack of circular imports causes occasional annoyance but keeps the tree clean, forcing a clear demarcation between packages. As with many of the design decisions in Go, it forces the programmer to think earlier about a larger-scale issue (in this case, package boundaries) that if left until later may never be addressed satisfactorily.

  Having debugged cyclic dependency problems several time in a large project, I used to say, “If a project is written in Go, we could hire any Go programmer and they will never cause a single dependency cycle, no matter how junior they are!”

• Airbnb’s style also forbids dependency cycles.

Implementation

It can be added by using import/no-cycle rule (ES6 import) or dependencies/no-cycle rule (require / import / export).

Impact

Cons:

• Annoyances.
• Harder to adopt in project that already contains cyclic deps.
• Harder to upgrade if project already contains cyclic deps.
• Cyclic deps can sometimes be useful.

Pros:

• In greenfield projects, we can just install standard and don’t have to worry about someone create cyclic deps, without having to jump through hoops and switch to standardx or eject to ESLint.
• So that “This module helps hold our code to an even higher standard of quality.”

[feross]

This sounds great. Happy to try enabling this in a future version of standard.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[michael-ciniawsky]

...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[dtinth]

😺

…

On Tue, Nov 27, 2018, 6:14 AM stale[bot] ***@***.*** wrote: This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1119 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALycKlyUX1lNSG_XIDZ_QvmVG1XNqK8ks5uzHXtgaJpZM4Tqw72> .

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[LinusU]

Would still like to see this ☺️

If anyone wants to make a PR against the config repo, and compile a report of how many repositories this would break, that would be awesome 👍

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[LinusU]

Would still like to see this ☺️

If anyone wants to make a PR against the config repo, and compile a report of how many repositories this would break, that would be awesome 👍