You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
And that would be a bit dynamic, as it would also support the possibility of having a common layer definition and a module with its own layer definition:
For each namespace the clj-depend analyzer would check if the namespace belongs to any of the modules. If the identified module has a layer definition it will be used, otherwise the common layer definition will be used.
If there is no modules key declared the behavior will be the same as today.
The text was updated successfully, but these errors were encountered:
If a rule of the module override a rule of common layers, what will be considered? A think today it already happens if we create 2 rules that override each other in common layers but i did not understand the current behavior tbh
To support for modular projects I thought of creating a
modules
key in the root of the config as today we already havelayers
.Something like modules sharing a common layer definition:
And that would be a bit dynamic, as it would also support the possibility of having a common layer definition and a module with its own layer definition:
Or even each module having its own layer definition:
For each namespace the clj-depend analyzer would check if the namespace belongs to any of the modules. If the identified module has a layer definition it will be used, otherwise the common layer definition will be used.
If there is no
modules
key declared the behavior will be the same as today.The text was updated successfully, but these errors were encountered: