illright
commented
3 weeks ago Hi! Thanks for this perspective, it's very valuable. Sometimes I get a few perspectives like this and then go through an existential crisis of sorts and then come out with very interesting realizations. Something that's possibly intended for FSD 2.2. I'll be keeping this in mind.
The future plan of Steiger? There's a big feature coming up very soon, the new config format. After that we will explore further DX improvements for writing rules and auto-fixing. Then we will also tackle performance, CLI experience, editor extensions, etc. That's the near-term roadmap.
As for extensibility, I think that the new config format will go a long way towards achieving that, but the one big hurdle that is currently very difficult to overcome is additional layers. As I said, maybe a future version of FSD will relax the layer standardization and allow adding more layers, but with the current spec, that's how it is. I'd be interested to hearing your experience with the current spec of FSD, your challenges and pain points, also about the cross-imports.
And I don't think this will be applicable to most projects based on FSD
Why so?
Hey! I know this issue not for current missions, but I want to discuss future of steiger and possibility to extend them for FSD-like architecture. I have already created an issue about possibility to write self rules (https://github.com/feature-sliced/steiger/issues/35). By now, I understand, this feature doesn't solve a more general problem. How I cant lint my architecture using steiger, If I have a more complex architecture which build on FSD.
I think devs who work on any big project build on FSD introduces local architectural abstractions and its own rules that are specific to the project at some point in time. And its logical growth, since the methodology does not cover absolutely all cases.
For example, we use cross-imports on entity layer (yes, I know about
@x, but we decide not to use it). Or we use a few new layers as abstract-widgets (abstract widgets which used in other widgets) or page-drawers (we have addition level of navigation into drawer on top of regular pages. In fact, these are the same pages, but we decided to separate them semantically). Current packagesteiger-plugin-fsdis strictly made for the basic set of layers (has high coupling with@feature-sliced/filesystem) and I don't see any chance to extend it for our project. Now we can't usesteiger, because I can't extend it (without a complete rewrite@feature-sliced/filesystemandsteiger-plugin-fsd).So, I would like to see about future plan of steiger. What a development strategy of this library? And I don't think this will be applicable to most projects based on FSD, if steiger will be developed as only set of strict rules for a methodology without the possibility of extension.