LINT(GET-STARTED): Check customization of config

[azinit]

Description

Add posibility to customize config by "concepts"-presets

We should support at least these options for integration:

• [x] Option 1. All recommended

  "I want all recommended boundaries"

• [x] Option 2. Only one specific

  "I want ONLY layers-boundaries / slice-boundaries / public-api-boundaries / import-order-boundaries / ... "

• [x] Option 3. Only few specific

  "I want ONLY layers-boundaries AND private-imports-boundaries"

• [ ] Option 4. Customize impl of configs (see #45)

  • [ ] "I want to enable shared/styles in public-api linting"
  • [ ] "I want to add my own layer into existing"

Suggestion

As variant, to split these options by eslint rules presets:

But if you have better ideas - you're welcome ✊

// Option 1.  All recommended
extends: [
   "@feature-sliced/recommended"
],
// Option 2.  Only one specific
extends: [
   "@feature-sliced/rules/layers",
   // OR "@feature-sliced/rules/slices"
   // OR "@feature-sliced/rules/private-imports"
   // OR "@feature-sliced/rules/import-order"
],
// Option 3. Only few specific
extends: [
   "@feature-sliced/rules/layers",
   "@feature-sliced/rules/private-imports",
],
// Option 4. Customize impl of configs
// No ideas... Maybe "initConfig(...)" setup-helpers?

[Krakazybik]

посмотреть

[Krakazybik]

jetBrains

[Krakazybik]

"@feature-sliced/rules/layers", "@feature-sliced/rules/slices" А есть ли смысл отделять эти концепции? Могут ли они понадобиться одна без другой? Если да, то можем, отделить их на другой итерации? т.к. пока что это одно правило и думаю это стоит сделать тогда в рамках отдельного PR.

[azinit]

"@feature-sliced/rules/layers", "@feature-sliced/rules/slices" А есть ли смысл отделять эти концепции? Могут ли они понадобиться одна без другой?

Ага)

Одно дело когда у тебя одна фича дергает другую фичу (slices) И совсем другое - когда shared импортит pages (layers)

[azinit]

Если да, то можем, отделить их на другой итерации? т.к. пока что это одно правило и думаю это стоит сделать тогда в рамках отдельного PR.

Но да, это не значит, что эти правила надо дробить на несколько отдельных сразу нужно Щас скорее правильно, что они находятся в layers-slices-boundaries

Но тут речь и о том, что конфиг конкретного правила должен как-то экспортироваться частями (у того же publicApi тоже может быть несколько подправил: private-imports, relative-imports, unified-api, ...)

Думаю даже, что и imports-order в каком-то роде относится к public -api 🤔

[azinit]

Если оч сложно сейчас, то можно конечно на отдельные правила попилить пока

Но это нужно прям на этой итерации, т.к. гораздо проще и профитнее придерживаться того же layers-boundaries в легасишном проекте Чем расцеплять слайсы между собой (slices-boundaries)

[Krakazybik]

тогда заведёшь ишью?

[Krakazybik]

на самом деле у нас возможности так гибко манипулировать конфигами нет =( даже параметры не можем прокидывать

[azinit]

тогда заведёшь ишью? Так эта ишью для этого и нужна как раз)

Чтобы что-то попилить, что-то в пресеты

[Krakazybik]

Вот собственно проблема, конфиги заменяют друг друга.

https://user-images.githubusercontent.com/1334019/145885611-b3677ad5-30c7-4d9a-bc97-eeb2997c5fd4.mp4

[Krakazybik]

Решение: заводим legacy-boundaries в котором будет только что там для легаси, и layers-slices-boundaries. И подключается либо один, либо другой.

[azinit]

@Krakazybik Проблему понял, но недопонял немног - а что за legacy?)

[Krakazybik]

я думал ты про v1.0

[Krakazybik]

ну или only-layers-boundaries, не суть в названии

[azinit]

ну или only-layers-boundaries, не суть в названии

Ну т.е. грубо говоря, придется сделать комбинаторные конфиги, чисто из-за того что в layers-slices один другой перетирает, если отдельно подключать - верно понял мысль?

[Krakazybik]

агась

[azinit]

Хммм, досадно однако) Ладно, тогда давай пока посмотрим, насколько другие опции можно удовлетворить

Мб получится что узнать по ресерчу с кастомизацией по параметрам

Или вдруг найдешь способ, как можно без комбинаторных конфигов совмещать все это дело

[azinit]

Ближе к среде сам посмотрю еще подробней, но спс что сообщил о проблеме ✊

[Krakazybik]

https://user-images.githubusercontent.com/1334019/146669670-006d81c4-0bd9-4218-8bfe-b57a6738a9a6.mp4

[Krakazybik]

@feature-sliced/eslint-config - все рекомендованные индекс можно в принципе переименовать в recommended, если надо чтоб recommended на конце было. ну или импортить из rec индекс

[azinit]

@feature-sliced/eslint-config - все рекомендованные индекс можно в принципе переименовать в recommended, если надо чтоб recommended на конце было. ну или импортить из rec индекс

Выглядит оч круто!

@Krakazybik А можешь пож подсказать - можно ли экстендиться от конфига без явного указания /eslint-config/**?

Т.е. сразу @feature-sliced/rules/import-order

По идее же должен подлавливать нормально 🤔

[Krakazybik]

Выглядит оч круто!

@Krakazybik А можешь пож подсказать - можно ли экстендиться от конфига без явного указания /eslint-config/**?

Т.е. сразу @feature-sliced/rules/import-order

По идее же должен подлавливать нормально thinking

Неа, не хочет почему-то.

[Krakazybik]

у JB тоже так

[azinit]

Блен, печально)

[azinit]

Но ладно, зато хоть как-то работает

Потом энивей до собственного плагина дойдет 😄

[Krakazybik]

Блен, печально)

ну не так уж и страшно =)