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:

• Option 1. All recommended

  "I want all recommended boundaries"

• Option 2. Only one specific

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

• Option 3. Only few specific

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

• Option 4. Customize impl of configs (see LINT(CUSTOM): Add advanced customization of config #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]

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