depRules on sub-modules

[michaelbe812]

Given the following directory structure:

feature-a/
├── api/
├── smart-components/
├── state/
│ ├── feature-a.actions.ts
│ ├── feature-a.effects.ts
│ ├── feature-a.model.ts
│ └── feature-a.reducer.ts
├── types/
├── ui-components/
└── utils/

Within state we have the typical NgRx-specific files.

I have the following modules and depRules defined:

export const config: SheriffConfig = {
  modules: {
    'features/feature-a': {
      'api': ['type:api'],
      'smart-components': ['type:smart-components'],
      'types': ['type:types'],
      'ui-components': ['type:ui'],
      'utils': ['type:util'],
      'state': ['type:state'],
    },
  }, 
  depRules: {
    root: ['noTag', 'type:smart-components'],
    noTag: ['noTag', 'root'],
    'type:smart-components': ['type:ui', 'type:types', 'type:api', 'type:util', 'type:state'],
    'type:ui': ['type:ui', 'type:types', 'type:util'],
    'type:util': ['type:types', 'type:util'],
    'type:types': ['type:types'],
    'type:api': ['type:types', 'type:util', 'type:api'],
    'type:state': ['type:types', 'type:util', 'type:state', 'type:api'],
  },
};

Let's focus only on the rules which targets the state. Right now we defined that only files within smart-components can access the state.

I would like to achieve the following:
ui-components are allowed to import from the **.actions.ts within state, so the file feature-a.actions.ts.

Is this somehow possible without creating sub-folders in state?

If it is not possible would this be a feature that would make sense to land into sheriff?

In terms of Sheriff rules we need something like this:

• define a module e.g. via file-pattern matching state/**.actions.ts: ['type:state-actions']
• a depRule for type:state-actions

Now the big question is how sheriff will then make sure to handle this somehow contradicting rule.

I hope it is somehow clear what I am trying to achieve 😅

[rainerhahnekamp]

Yes, it is totally clear, and it is very similar to what we discussed in #19.

I think we need to be able to define a module via file-patterns. We just have to write in the docs that this is an edge case, because you currently just have to look at the directory to know to which module it belongs to. That would change dramatically.

We also need think about edge cases. What happens if a "static" module is applied to the same directory as one with selectors?

export const config: SheriffConfig = {
  modules: {
    'state': [
      { selector: '**/*actions.ts', tags: ['type:state-actions'] },
      { tags: ['type:state'] }
    ],
  }
};

Does the first one always get priority,

What happens with files that are matched by multiple modules?

export const config: SheriffConfig = {
  modules: {
    'state': [
      { selector: '**/*actions.ts', tags: ['type:state-actions'] },
      { selector: '+state/*.ts', tags: ['type:state-actions'] },
    ],
  }
};

What happens to files that do not fall under the file selection? Are they now part of the parent module, which would be root in most cases?

export const config: SheriffConfig = {
  modules: {
    'feature-a': 'type:feature',
    'feature-a/state': [
      { selector: '**/*actions.ts', tags: ['type:state-actions'] }, // reducers.ts are now part type:feature?
    ],
  }
};

---

In your case I would put the actions outside the state directory. The old recommendation of NgRx with putting everything into a +state directory didn't make it obvious that actions (events) are more globally and should be separated.

[michaelbe812]

The mentioned issue The mentioned issue more or less describes what I want to achieve - great that this is already on the roadmap. Maybe another opportunity to contribute! :)
Sorry for the short answer and not going more into detail about your response - the Github UI is so laggy atm

[rainerhahnekamp]

Maybe another opportunity to contribute! :)

Definitely