[niedzielski]

Do you use any tooling to detect this? I had this issue some years back and it wasn't obvious. My builds just took longer and longer.

[pc2g4d]

I've been using DPDM: https://github.com/acrazing/dpdm

These are my package.json scripts for detecting cycles:

  "cycles": "run-p cycles:client cycles:server",
  "cycles:client": "dpdm client/src/\*/\*.ts --exit-code circular:1",
  "cycles:server": "dpdm server/src/server.ts --exit-code circular:1",

The exit code is set like that so that the CI will fail on cycles, since we run this in our CI build.

I also hear people use ESLint, probably this: https://github.com/import-js/eslint-plugin-import/blob/main/...

The fact that the compiler itself doesn't error on cycle imports, and that the errors caused by those imports are so opaque, seems like an oversight to me.

[ly3xqhl8g9]

The best™ way I found was the dumb way: at emit time (./build, ./dist in package "one") simply copy the new build to all the required dependants across the local file system (two/node_modules/one/build, three/node_modules/one/build, etc.). It's just dumb enough to be good enough. I stress tested with around 100 packages and it works rather decent, especially when all the packages are using esbuild/nodemon for development and restart on node_modules update. To automate this I have added a "develop" [1] feature in a tool I made, joiner, for running tasks over multi-repos.

[1] https://github.com/plurid/joiner#development

[Fudgel]

There's an eslint plugin to detect circular dependencies: https://github.com/import-js/eslint-plugin-import/blob/main/...

[no_wizard]

Dependency Cruiser works great, can even render visuals:

https://github.com/sverweij/dependency-cruiser

NX[0] also has logic for handling this issue

[0]: https://nx.dev/