search

feature-sliced / steiger

Universal file structure and project architecture linter
https://www.npmjs.com/package/steiger
MIT License
65 stars 4 forks source link

Question: Non-descriptive segment name #43

Closed EliseyMartynov closed 3 months ago

EliseyMartynov commented 3 months ago

Сейчас имена сегментов захардкожены в линтере? И как я понимаю это правило не закастомизировать в данный момент: issue?

image

illright commented 3 months ago

Yes, for now they are all hard-coded with no customization. #33 does discuss the possibility of introducing options to rules, and we will consider it for this rule too, but why do you want to change it? Would you prefer to keep the types segment in your project?

EliseyMartynov commented 3 months ago

Да, потому что такой инструмент должен быть гибким. Одни команды хотят писать типы ближе к месту объявления, другие хотят выносить типы в отдельный сегмент, с т.з. FSD препятствий для этого не вижу. Или есть critical concerns на эту тему? Кажется FSD никак не ограничивает пользователей создавать кастомные сегменты, за исключение тех, против которых методология боролась изначально (components, containers, ducks etc.)

illright commented 3 months ago

The types segment is conceptually no different from components — it describes what the contents are, not what they are used for, so this is a violation of this rule.

In my opinion, teams that choose to have such segments should either disable this rule entirely or reconsider. What do you think?

EliseyMartynov commented 3 months ago

Yep, fairly enough.

uskov-anton commented 3 months ago

The types segment is conceptually no different from components — it describes what the contents are, not what they are used for, so this is a violation of this rule.

@illright You are right from a formal point of view. On the other hand, there is a desire to separate types from runtime code. What does the methodology offer in this case?

illright commented 3 months ago

@uskov-anton

On the other hand, there is a desire to separate types from runtime code. What does the methodology offer in this case?

The methodology prompts you to think about what is the reason behind this desire. If you separate related modules purely because one is a type and the other is runtime code, you're stretching out the "spider of dependencies", which means that code changes will affect more of the project, and it will be harder to keep inter-dependencies out. From FSD's perspective, there is no good reason to separate types from runtime code, which is why it's encoded into this rule. If you disagree, I'd gladly hear your reasoning