Add options to allow cross imports between slices in "fsd/forbidden-imports"

[noveogroup-amorgunov]

Hey! Sometimes I use cross-imports between widgets (any slices in a same layer) and want to describe it in the config like that:

{
  files: [
    'src/widgets/popular-products/*',
  ],
  rules: {
    // 
    'fsd/forbidden-imports': ['off', [
      'src/widgets/base-product-slider/*',
    ]],
  },
},

Could we discuss this option? I know that this violates the FSD, but sometimes is very useful, and now I have to completely turn off the rule for the slice like:

{
  files: [
    'src/widgets/popular-products/*',
  ],
  rules: {
    'fsd/forbidden-imports': 'off',
  },
}

[illright]

Hi! Yeah, I see how the current ruleset doesn't serve your use case. I think what you're describing can be achieved by splitting forbidden-imports into two rules, no-cross-imports and no-higher-level-imports, that can be individually disabled. We could even implement it in a non-breaking manner by adding these two rules and leaving them off in the recommended config, but still allowing people to manually turn them on for granular control.

Would you like to try to implement it?

[noveogroup-amorgunov]

We could even implement it in a non-breaking manner by adding these two rules and leaving them off in the recommended config, but still allowing people to manually turn them on for granular control.

Good idea

Would you like to try to implement it?

Maybe I will try to do it in the future)

[gwbaik9717]

@illright, would it be okay if I took on this issue?

We could even implement it in a non-breaking manner by adding these two rules and leaving them off in the recommended config, but still allowing people to manually turn them on for granular control.

Though I think it might be better to enable these two rules by default in the recommended config, and allow users to opt out for granular control instead.

Also, I have another question about the issue: In the above issue describe, I think using @x to specify slice for cross-imports would be more feature-sliced approach. Is there any reason why we cannot use @x in this case?

[illright]

@gwbaik9717 it would certainly be okay :)

Though I think it might be better to enable these two rules by default in the recommended config, and allow users to opt out for granular control instead.

That would be a breaking (albeit minor) change. If someone had the forbidden-imports rule disabled, then their pipeline might break with the addition of these two rules if they were enabled by default.

I'll also take the liberty to answer the question about the issue because I feel like I know the answer — if Alexander's team has decided that they don't want to restrict cross-imports between widgets, that's certainly irregular for FSD, but if it makes their life easier and not harder, then all the power to them

[gwbaik9717]

Thank you for the answer!

Just to clarify:

To ensure backward compatibility, we’re keeping 'fsd/forbidden-imports' as-is while introducing two new rules ('fsd/no-cross-imports' and 'fsd/no-higher-level-imports') that split its functionality.

I have two questions.

1. Deprecation Plan: Once the two new rules are fully implemented, would 'fsd/forbidden-imports' be deprecated and eventually removed in the future?
2. Rule Conflict Handling: In cases like the example below, we might need to define how these rules interact—particularly when 'fsd/forbidden-imports' is set to 'off' while the new rules are enabled. Should this disable both new rules, or should they work independently?

{
  files: [
    'src/widgets/popular-products/*',
  ],
  rules: {
    'fsd/forbidden-imports': 'off', // which makes both 'fsd/no-cross-imports' and  'fsd/no-higher-level-imports' off
    'fsd/no-cross-imports': 'on',
     'fsd/no-higher-level-imports': 'on'
  },
},

[illright]

Yes, forbidden-imports should be deprecated, and we should add guidance to the docs that the two counterparts exist and should be used instead.

Come to think of it, it would be nicer if we could remove the forbidden-imports rule already and somehow make it an alias for the two other rules, but we don't have infrastructure in Steiger to do that, so we probably can't do that.

This leads me to the conflict handling — there will be no conflicts, these rules will function completely independently. If someone turns on no-cross-imports without turning off forbidden-imports, they will get duplicate diagnostics, which is no big deal in itself, but will also prompt them to turn forbidden-imports off.

[gwbaik9717]

That makes perfect sense now. Thank you for the clear explanation!

[illright]

Hey! Sorry for the delay in releasing, this is now available with the latest @feature-sliced/steiger-plugin