LINT: Resolve public-api/lite (Need your feedback!)

[azinit]

Were added by #83 for public-api rule by @Krakazybik

Should be merge with base config, or stay separated "more lite" version

Why experimental?

#75 (comment)

Variant 1: public-api/lite (lite)

Without SegmentsAPI/InnerAPI restrictions

// 👍 Pass
/** @path entities/order/index.ts */
import {...} from "./ui";
/** @path features/auth-form/ui/form/content.tsx */
import {...} from "../../model";

// 👍 Also Pass
/** @path widgets/issue-details/index.ts */
import {...} from "./ui/details"
/** @path features/auth-form/index.ts */
import {...} from "./ui/form"
/** @path entities/order/index.ts */
import { saveOrder } from "./model/actions";
/** @path shared/ui */
import { Button } from "./button/button";

Variant 2: public-api (base)

With SegmentsAPI/InnerAPI restrictions

// 👍 Pass
/** @path entities/order/index.ts */
import {...} from "./ui";
/** @path features/auth-form/ui/form/content.tsx */
import {...} from "../../model";

// 👎 Fail
/** @path widgets/issue-details/index.ts */
import {...} from "./ui/details"
/** @path features/auth-form/index.ts */
import {...} from "./ui/form"
/** @path entities/order/index.ts */
import { saveOrder } from "./model/actions";
/** @path shared/ui */
import { Button } from "./button/button";

Please, leave your vote below:

"👍" - if you prefer to use public-api/lite at base config (less restrictions by default config)
"👎" - if you prefer to use public-api/lite as alternative separated config (more restrictions by default config)
"👀" - if you aren't sure

Feel free leave below your comments

[azinit]

@feature-sliced/core @feature-sliced/contributors Поделитесь мнением пож 🤔

[azinit]

@illright @pzyryanov1995 @tednaaa @SQReder @Affiction @Kelin2025 Тоже можете оставить свой фидбек тут

[illright]

Проголосовал за то, чтоб оставить менее ограничивающие настройки по умолчанию:

• По моему опыту, проект должен быть реально большим, для того, чтоб добавление деклараций публичного API сегментов не ощущалось, как бойлерплейт. До такого размера дорастает далеко не каждый проект, да и не сразу, к тому же;
• Люди, пробующие FSD в своих проектах, но не знающие об этом правиле, смогут накатить линтер гладко и получить удовлетворение, а впоследствии, исследуя настройки линтера, смогут узнать, что можно внедрить больше ограничений. Как strict в TypeScript.

[SQReder]

Придерживаюсь на проектах более строгой версии конфига. Лайт версия может пригодится для переходных состояний, к примеру, или простро по вкусу быть людям

С другой стороны, если мы посмотрим на практику конфигураций в целом, то значения по-умолчанию, обычно, более мягкие. И те, кому нужна дополнительная строгость подключают дополнительные правила и ограничения

[Krakazybik]

Люди, пробующие FSD в своих проектах, но не знающие об этом правиле, смогут накатить линтер гладко и получить удовлетворение, а впоследствии, исследуя настройки линтера, смогут узнать, что можно внедрить больше ограничений. Как strict в TypeScript.

С этим не соглашусь, скорее всего будет куча проблем по boundaries, и как раз конфиг придётся распиливать и вводить частями. По дефолту, в самом начале миграции на FSD, кажется, будет бить по рукам со всех сторон и будет мульён ошибок со стороны линтера. Мы работаем над этим, чтоб можно было настроить разный уровень строгости, но как мне кажется, это точно не про дефолтный конфиг.

[illright]

С этим не соглашусь, скорее всего будет куча проблем по boundaries, и как раз конфиг придётся распиливать и вводить частями.

Возможно, мы не так друг друга поняли. Я предлагал сделать по умолчанию конфиг с меньшим количеством ошибок, так что при затаскивании лучше иметь меньше ошибок, чем больше, на мой взгляд. Ты предлагаешь, чтоб дефолтный конфиг бил со всех сторон?

[azinit]

Возможно, мы не так друг друга поняли. Я предлагал сделать по умолчанию конфиг с меньшим количеством ошибок, так что при затаскивании лучше иметь меньше ошибок, чем больше, на мой взгляд. Ты предлагаешь, чтоб дефолтный конфиг бил со всех сторон?

При таком подходе, у нас тогда и "warn" вместо "error" по дефолту должны быть в конфигах? 🤔

[Krakazybik]

Возможно, мы не так друг друга поняли. Я предлагал сделать по умолчанию конфиг с меньшим количеством ошибок, так что при затаскивании лучше иметь меньше ошибок, чем больше, на мой взгляд. Ты предлагаешь, чтоб дефолтный конфиг бил со всех сторон?

Я придерживаюсь мнения, что в начале миграции на FSD, совсем другие проблемы, и от ESLint будет больше проблем чем пользы. Т.к. проблемы не с тем как разложить, а как понимать это всё и принимать.

[illright]

При таком подходе, у нас тогда и "warn" вместо "error" по дефолту должны быть в конфигах? 🤔

Не, там, где грубые ошибки, там должен быть error обязательно. Я имею в виду, что отсутствие декларации публичного API сегментов — не грубая ошибка, и лучше не наказывать новичков за это, даже warning-ом. Когда они комфортно устроятся с линтером FSD и начнут копаться в настройках, они найдут эту настройку, заведут задачку по переходу, и сделают код более строгим.

[Krakazybik]

Возможно, мы не так друг друга поняли. Я предлагал сделать по умолчанию конфиг с меньшим количеством ошибок, так что при затаскивании лучше иметь меньше ошибок, чем больше, на мой взгляд. Ты предлагаешь, чтоб дефолтный конфиг бил со всех сторон?

Я уже как-то говорил, что считаю eslint-config набором бест-практикс. Также и любой другой конфиг, ограничивает и привносит то, обо что, как считают, можно споткнуться.

[azinit]

@feature-sliced/core Мб вам еще будет что добавить? 🤔