New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable Circular Dependency Check #13842
Comments
An option to do this would be appreciated. Bazel solves this by building the dep graph per target. There's no such thing as a project (package in Bazel) having dep edges that all targets must use, which appears to be the case in nx. Is there a way today to express a graph for a project containing 3 workspaces:
None of the three packages have any build deps, but all three depend on the linter being built to lint, and all three depend on the tester being built to test. Is there a simple way to express this in nx today? |
It would be great to split
Example: Given NX team opinion on circular dependencies situation, example provided in the official docs (https://nx.dev/core-features/enforce-project-boundaries) actually does promote circular dependencies:
At a first glance one could think that even self-import is allowed. We obviously want to prevent self-imports (via both library alias and via relative import specifier) but circular imports between two libraries must be allowed without disabling the entire valuable rule. I hope this makes sense to NX team. We would highly appreciate enhancements in that quite critical (for large projects) space. |
Hi , I am also facing similar issue, some core lib which test files import stuff from other libs. I think the best approach would be splitting up the core libs into two projects, one core lib, another core-testing. But also I think it might be a possible solution. I guess "excludedFiles" currently does affect filtering out files in the lib being lint but it does not filter the files in the graph for circular dependency checks. For example with "excludedFiles": ["*.spec.ts"]
When running lint for core , spec file will be skip and lint finishes successfully What do you think if the "excludedFiles" filter out the files also in other projects ? |
Hi @dcrdev maybe I have a temporal solution for you. While in my team we've decided to go for moving tests to another project, in your case you could use an alias instead of a new project. Then export everything from the conflictive package in a ts file at the root folder. eg {
"paths": {
...
"@my-workspace/lib-a/testing": "./testing.ts"
...
}
}
{
"extends": "tsconfig.base.json"
"files": ["testing.ts"]
}
export * from '@my-workspace/lib-a' Then replace This is a tricky way, because no checks will be found for that package, but all the other projects linting checks will work as usually. |
there's also the |
How is this still not supported? |
Description
Our project is composed of a core, testing and several plugin packages, our testing package is utilized by our e2e tests to spin up a test server, the package has a dependency on core. Our core package has its own e2e tests and these utilize the testing package, within our core package we have a dev dependency on the testing package.
Currently I cannot build the solution because it results in Nx complaining about the circular dependency, it seems like a perfectly valid setup to me; we don't have a build time dependency on testing in core, we have a dependency in our tests only.
I have seen the various issues related to this and there are two proposed suggestions:
Use explicit dependsOn directives with the !package-name syntax
This does not work at all in my situation
Move tests to a seperate package
Would be impractical to do this, because not only would core require an e2e testing package, so would all of our plugins and their siblings.
It would be helpful if there were a way to bypass this check somehow
Motivation
It's widely requested, see: #2570, #10290, #9645
As of yet none of those discussions talk about a use case where you have a plugin ecosystem for which it's extremely beneficial to have a standardised framework for writing tests.
Suggested Implementation
A couple of possible implementations:
Alternate Implementations
Another implementation might be to ignore circular dependencies when analyze source files is set to false.
The text was updated successfully, but these errors were encountered: