4 ms·

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.

no_wizard 4y ago
Dependency Cruiser works great, can even render visuals: https://github.com/sverweij/dependency-cruiser https://github.com/sverweij/dependency-cruiser NX[0] also has logic for handling this issue [0]: https://nx.dev/ https://nx.dev/
pc2g4d 4y ago
I've been using DPDM: https://github.com/acrazing/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/docs/rules/no-cycle.md 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.
Fudgel 4y ago
There's an eslint plugin to detect circular dependencies: https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-cycle.md https://github.com/import-js/eslint-plugin-import/blob/main/...
ly3xqhl8g9 4y ago
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 https://github.com/plurid/joiner#development

no_wizard 4y ago

Dependency Cruiser works great, can even render visuals: https://github.com/sverweij/dependency-cruiser https://github.com/sverweij/dependency-cruiser NX[0] also has logic for handling this issue [0]: https://nx.dev/ https://nx.dev/

pc2g4d 4y ago

I've been using DPDM: https://github.com/acrazing/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/docs/rules/no-cycle.md 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.

Fudgel 4y ago

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

ly3xqhl8g9 4y ago

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 https://github.com/plurid/joiner#development