Add the CircularDependencyPlugin to Webpack configuration
It's very useful to be able to know when module A depends on B, and B depends on A. Adding this plugin would provide developers insight into circular dependencies.
Circular dependencies and issues they cause, recently came up as more of a blocking behavior when upgrading from node14 runtime to node16 which is now making the build process to exhaust all available memory, which wasn't the scenario in the past.
We have discussed the circular dependencies, where it should be checked and who should do it, while we were addressing these issues as part of Engine 3x -> 4x upgrade process. We have suggested clients to use a simple CLI tool from npm called madge to scan and detect circular dependencies, independent from the build system.
Example command: npx madge --circular <folder-to-scan>
Another reason the team is resistant to not introduce more webpack plugins, or open webpack configuration for extensibility (even though we understand this is a need) is that; we're actively exploring other build systems to improve our build times. That's why we will defer this need/idea and suggest our clients utilizing existing circular dependency detection mechanism like madge.
Greg MacGregor
Hi Greg, JP,
Circular dependencies and issues they cause, recently came up as more of a blocking behavior when upgrading from node14 runtime to node16 which is now making the build process to exhaust all available memory, which wasn't the scenario in the past.
We have discussed the circular dependencies, where it should be checked and who should do it, while we were addressing these issues as part of Engine 3x -> 4x upgrade process. We have suggested clients to use a simple CLI tool from npm called madge to scan and detect circular dependencies, independent from the build system.
Example command:
npx madge --circular <folder-to-scan>
Another reason the team is resistant to not introduce more webpack plugins, or open webpack configuration for extensibility (even though we understand this is a need) is that; we're actively exploring other build systems to improve our build times. That's why we will defer this need/idea and suggest our clients utilizing existing circular dependency detection mechanism like madge.
We made use of https://www.npmjs.com/package/eslint-plugin-import
To ESLint our file import statements, for various possible issues.
Along with https://www.npmjs.com/package/eslint-import-resolver-alias
To support some path aliases and ignoring "fusion:*" module imports.
Here is some of our .eslintrc.json file, with related settings:
{
"extends": [
"plugin:import/errors",
"plugin:import/warnings"
],
"settings": {
"import/resolver": {
"alias": {
"map": [
["~/components", "./components"],
["~/content", "./content"],
["~/resources", "./resources"]
],
"extensions": [".js", ".jsx", ".json", ".scss", ".css"]
}
}
},
"rules": {
"import/no-unresolved": [2, { "ignore": ["fusion:*"] }],
"import/no-self-import": 2,
"import/no-cycle": 2
}
}
This could be fixed by allowing the Webpack setup to be configurable
We'll need to evaluate the performance impact of adding this webpack plugin.