LINT: Resolve import-order/experimental (Need your feedback!)

[azinit]

Were added by #82 for import/order rule by @Krakazybik

Should be merged with base config, or deleted at all

Why experimental?

#75 (comment)
#75 (comment)

Variant 1: import-order/experimental

With spaces and reverted order ("from abstract - to specific")

import axios from "axios";                           // 1) external libs

import { debounce } from "shared/lib/fp";            // 2.1) Layers: shared
import { Button } from "shared/ui";                  // 2.1) Layers: shared

import { authModel } from "entities/auth";           // 2.2) Layers: entities
import { commentModel } from "entities/comment";     // 2.2) Layers: entities
import { postModel } from "entities/post";           // 2.2) Layers: entities

import { LoginForm } from "features/login-form";     // 2.3) Layers: features

import { Header } from "widgets/header";             // 2.4) Layers: widgets

import { data } from "../fixtures";                  // 3) parent
import { getSmth } from "./lib";                     // 4) sibling

Variant 2: import-order (base)

import axios from "axios";                           // 1) external libs
import { Header } from "widgets/header";             // 2.1) Layers: widgets
import { LoginForm } from "features/login-form";     // 2.2) Layers: features
import { authModel } from "entities/auth";           // 2.3) Layers: entities
import { commentModel } from "entities/comment";     // 2.2) Layers: entities
import { postModel } from "entities/post";           // 2.3) Layers: entities
import { Button } from "shared/ui";                  // 2.4) Layers: shared
import { debounce } from "shared/lib/fp";            // 2.4) Layers: shared
import { data } from "../fixtures";                  // 3) parent
import { getSmth } from "./lib";                     // 4) sibling

Please, leave your vote below:

"👍" - if you prefer to use import-order/experimental at stable config
"👎" - if you prefer to use import-order at stable config
"👀" - if you aren't sure

Feel free leave below your comments

[azinit]

@feature-sliced/core @feature-sliced/contributors please, leave your feedback

[PUndef]

В первом варианте мне нравится что порядок слоёв такой, какой должен быть по методологии. Однако нет разделения групп, это достаточно удобная опция, по крайней мере для меня

[SQReder]

Плюсую разделение групп, как стандарт

[PUndef]

В рамках своего предложения Я говорю о такого рода разделении (чтобы не было недопонимания):

import axios from "axios";                           // 1) external libs

import { Header } from "widgets/header";             // 2.1) Layers: widgets

import { LoginForm } from "features/login-form";     // 2.2) Layers: features

import { authModel } from "entities/auth";           // 2.3) Layers: entities
import { commentModel } from "entities/comment";     // 2.2) Layers: entities
import { postModel } from "entities/post";           // 2.3) Layers: entities

import { Button } from "shared/ui";                  // 2.4) Layers: shared
import { debounce } from "shared/lib/fp";            // 2.4) Layers: shared

import { data } from "../fixtures";                  // 3) parent
import { getSmth } from "./lib";                     // 4) sibling

[PUndef]

но вроде как некоторые топят за такой вариант. в целом Я тоже не против такого

import axios from "axios";                           // 1) external libs

import { Header } from "widgets/header";             // 2.1) Layers: widgets
import { LoginForm } from "features/login-form";     // 2.2) Layers: features
import { authModel } from "entities/auth";           // 2.3) Layers: entities
import { commentModel } from "entities/comment";     // 2.2) Layers: entities
import { postModel } from "entities/post";           // 2.3) Layers: entities
import { Button } from "shared/ui";                  // 2.4) Layers: shared
import { debounce } from "shared/lib/fp";            // 2.4) Layers: shared

import { data } from "../fixtures";                  // 3) parent
import { getSmth } from "./lib";                     // 4) sibling

[azinit]

Поменял порядок, а то многие путают)
(сами пункты по существу не поменялись, эмодзи актуальны)

Еще раз:

👍 - за экспериментальный конфиг как стейбл
👎 - за базовый конфиг (без экспериментов) как стейбл

[Kelin2025]

Писал в треде, продублирую и сюда

TL;DR - считаю второй вариант нелогичным, а путь app -> shared в доке FSD исторической ошибкой, которую надо исправлять

---

В своих проектах я использую порядок npm пакеты -> shared -> entities -> features -> ... -> локальные
Аргументация элементарная:

• NPM-пакеты - самый недоступный и ультимативно абстрагированный уровень
• Shared - тут помимо UI и API тоже лежат локальные библиотеки, смысл схожий с пакетами
• Дальше, соответственно, все слои по порядку
• Пока не спустимся до локального слоя

Обратный порядок же превратит импорты в лютую кашу.
Предположим, что у нас страница. Будет следующее:

import axios from 'axios'             // Самый топ-левел (Возьмём его за 0)
import { Foo } from '@/widgets/foo'   // Виджеты (4)
import { Bar } from '@/features/bar'  // Фичи (3)
import { Bar } from '@/entities/baz'  // Сущности (2)
import { Button } from '@/shared/ui'  // Shared (1)
import { Smth } from './ui/Smth'      // Локальное от страницы (5)

И шо это за дичь?)) Как с американским форматом дат история выходит. Кому-то привычно, но для остальных - диссонанс.

---

Более того, мне не ясно, почему в методологии вообще сложился путь от app к shared. Такое направление с семантической точки зрения некорректно, потому что ты импортируешь из shared в сущности итд, а не наоборот.
Можно сказать "это путь зависимостей, мол, стрелка значит, что страница зависит от виджетов, фич итд". Однако, направление стрелки всё ещё будет некорректным, поскольку это зависимости вставляются в страницу, а не страница в них.
Здесь же складывается ощущение, что у нас библиотека сначала используется, а потом объявляется.

---

Если уж хочется - то можно это сделать опцией, но лично я категорически против принимать app -> shared за дефолтное поведение, это совершенно не логично.
А то, что в доке FSD написан такой порядок - это апелляция к доке, а не аргумент.

[unordinarity]

Упрощаю тезис @Kelin2025: импорты сортируются от глобальных к локальным, то есть блок импортов из слоёв должен быть отсортирован от shared к app, не наоборот.

[unordinarity]

Разделение импортов из слоёв по блокам - вопрос специфичный для конкретного проекта. На многих проектах в начале жизненного пути ещё нет портянок по 100 строк импортов и 1000 строк jsx, сортировать и разделять там почти нечего.

[SQReder]

Как ты заметил "в начале проекта". Мы же нацелены на тот, чтобы методология помогала на комплексных проектах, в том числе

В то время как разбивка не мешает на на небольшом количестве импортов, на больших она приносит свою пользу

[azinit]

В то время как разбивка не мешает на на небольшом количестве импортов,

Оч спорно)

Мы же нацелены на тот, чтобы методология помогала на комплексных проектах, в том числе

Но это не значит, что линтер должен халтурно обрабатывать на средних 🤔
Тут кажется небольшая подмена понятий

[azinit]

👀

https://www.freecodecamp.org/news/best-practices-for-react/