• With test running
• With config building
• With needed dependencies

Description

Wrong import order with aliased layers

Examples:

// Should be OK!
import { First } from '@features/first';
import { Second } from '@entities/second';
import { Third } from '@shared/third';

Reference

#75 (comment)

Glossary

• "External module" - entity/foo <-> entity/bar, entity/foo <-> shared/ui/button
• "Internal module" - entity/foo <-> entity/foo/ui, entity/foo/ui/smth <-> entitiy/foo/lib

Description

• Restrict relative imports for external modules (enforce for internalmodules)
• Restrict absolute imports for internalmodules (enforce for external modules)

Example

// Fail 👎 
// @path features/baz/model/index.ts
import { ... } from "../../bar" // Sibling feature-slice
import { ... } from "@/features/baz/model/smth" // Invalid access to internal resource as external module
// Pass 👍 
// @path features/baz/model/index.ts
import { ... } from "../lib" // Import of internal module as internal resource - no illegal
import { ... } from "../entities/foo" // Lower layer slice - no illegal
import { ... } from "@entities/foo" // Import as external module
import { ... } from "shared/ui/button" // Import as external module

Reference

feature-sliced/documentation#52 (reply in thread)

На случай, если найдутся получше для реализации тех же правил

• https://github.com/lydell/eslint-plugin-simple-import-sort
• https://github.com/sverweij/dependency-cruiser
• https://github.com/javierbrea/eslint-plugin-boundaries
• https://eslint.org/docs/4.0.0/rules/sort-imports
• https://github.com/SonarSource/SonarJS

Description

Покрыть пограничные кейсы каждого правила.

Reference

#32
ref

Problem

Every boundaries-unit config works good, but we shouldn't forget about common config usage

Units-configs shouldn't affect each other and we have to check it at integration tests

Steps

• #35
• #36

#55 (reply in thread)

Description

• Each unit test should work with typescript-runner
• Each integration test should work with typescript-runner
• Docs should has all required info about using with TypeScript

Reference

https://github.com/effector/eslint-plugin/blob/master/rules/no-getState/no-getState.ts.test.js

Description

Should work for each rule

• imports-order
• layers-slices
• public-api

Reference

// Pass
import { ... } from "entities/user";
import { ... } from "@/entities/user";
import { ... } from "@root/entities/user";
import { ... } from "@root/src/entities/user";
import { ... } from "~/entities/user";

Problem

• Compatibility (better decide "too earlier", than "too late")
• A lot of variations of rules for same concept

  PublicAPI: private-imports, segments-api, relative-imports, unified-api, ...
  Decomposition: layers-imports, slices-imports, ...

I have an app with react, effector, patronum, antd and bunch of other stuff

After i had added @feature-sliced/eslint-config, errors like this started to appear:

  2:26  error  Reaching to "effector-react/ssr" is not allowed  import/no-internal-modules
  3:23  error  Reaching to "patronum/delay" is not allowed      import/no-internal-modules

The problem is that imports like that are perfectly valid and intended by these libraries 🤷‍♂️
I suggest not to run import/no-internal-modules rule against imports from node_modules (or against non-feature-sliced paths at all)

Small reproduce: https://stackblitz.com/edit/fs-eslint-false-trigger?file=src/app/index.js
Run npm run lint in the terminal to see the issue

Description

Should work for each rule

• imports-order
• layers-slices
• public-api

Reference

// Pass
import { ... } from "entities/user";
import { ... } from "../entities/user";
import { ... } from "../../entities/user";
...

• Optimize built config?
  https://github.com/shashkovdanil/clean-publish#readme
  https://github.com/effector/eslint-plugin/blob/master/package.json#L28
• Rename "index.js" to "recommended"?
• More explicit "public" and "private" utils
  For ignoring redundant libs
  

@Krakazybik I suggest to collect here known issues after using 0.1.0 prototype versions (for quick fix)

Add remained options from #22

• Option 4. Customize impl of configs

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

• Option 2. Only atomized specific rules

  • Not "layers-slices" but "layers" or "slices"
  • Not "public-api" but "slices-public-api" or "segments-public-api"

    It's bad, that we prohibit two boundaries both implicitly

Add test cases from tasks:

• #10
• #11

Make it great again

• #18
• #19
• #20

Description

Impossible to disable rules by customized ruleIds
By IDE and by manual disabling

Reference

#75 (comment)

Problem

Package should have all required for usage at real projects

• Docs
• JS/TS Support
• Possibility to customize config (basely)

Steps

• #24
• #22
• #38
• #21
• LINT: Check messages
• Check by "share config" article
  https://eslint.org/docs/developer-guide/shareable-configs#creating-a-shareable-config

• Базово привести в порядок репу
• Поправить README
• Релизнуть 0.0.0 версию (чтобы забить место)
• Довести до yarn

После вливания #32 - тесты конфига и плагинов на валидность скипнуты тут т.к. правила подключаются в отдельных конфигах.

Возможные решения: если в extends находим локальные пути до конфигов, то идём в него и рекурсивно валидируем так всё, что найдём.

Можно в принципе не опускаться ниже чем на 1 уровень, т.к. я не думаю что мы упоримся в декомпозицию настолько, что будет актуальным рекурсивно ходить по конфигам 🤔

Compare with ready solutions (effector, airbnb, ...)

• Ignore redundant files in dist
• Check basic usage (recommended + custom)
• Other refinements
  • Remained docs refinements
• #22
  • Refine customizing?
  • Refine configs splitting?
  • Add exporting of "bootstrap-init" helper function?
• Rename rules (for preventing future problems):

  import-order
  - public-api-boundaries
  + public-api
  - layers-slices-boundaries
  + layers-slices

  • + Rename at README
• Rename local rules/index.md to README.md

Description

Each segment should have local public-api file declaration

/** @path features/smth/index.ts */
// Fail
export { SubmitButton } from "./ui/button";
export { SmthForm } from "./ui/form";
// Pass
export { SubmitButton, SmthForm } from "./ui";

/** @path features/smth/index.ts */
// Fail
export * from "./model/actions";
export { selectSmthById } from "./model/selectors";
// Pass
export * from "./model";
export * as smthModel from "./model";
export { selectSmthById, ... } from "./model";

ToRefine

• shared/ui no-required reexports?
• shared/lib no-required reexports?

With primary functional:

// Fail
import { Issues } from "pages/issues";
import { IssueDetails } from "features/issue-details"
import { Button } from "shared/components/button";

// Pass
import Routing from "pages"; // specific pages shouldn't be reexported
import { IssueDetails } from "features" // all features should be reexported, for usage
import { Button } from "shared/components"; // all components should be reexported, for usage

// Fail
import { Helper } from "./helpers";
import axios from "axios";
import { data } from "../fixtures";
import { Button } from "shared/components"
import { IssueDetails, RepoList } from "features"
import { debounce } from "shared/helpers"

// Pass
import axios from "axios"; // 1) external libs
import { IssueDetails, RepoList } from "features" // 2) features
import { Button } from "shared/components" // 3) shared/**
import { debounce } from "shared/helpers"
import { data } from "../fixtures"; // 4) parent
import { Helper } from "./helpers"; // 5) sibling

// Fail
import Routing from "../../pages"
import { IssueDetails } from "../features";
import { Button } from "../shared/components";

// Pass
import Routing from "pages"
import { IssueDetails } from "features";
import { Button } from "shared/components";

• With links to official docs articles
• At first - on eslint-plugin level (where is possible => without overengineering)
  • https://eslint.org/docs/rules/no-restricted-imports

• For quick-usage
• For quick rules docs navigation

Description

Shared segments should work with alias.

// pass
import { routeNames } from '@/shared/router';
import { fetchRules } from '@shared/api/rules';

Reference

#75 (comment)
#75 (comment)

Description

• Group unit configs and tests
• (If possible) Add base doc for each "rule-unit"

   // As variant
   // @see https://github.com/effector/eslint-plugin/tree/master/rules/no-getState
   📁 rules/
        📁 layers-slices/
              index.js          // config of boundaries
              fixtures.js       // test fixtures (if need)
              index.test.js     // unit test of boundaries
              index.md          // docs of boundaries (in future)
        📁 public-api/

Reference

https://github.com/effector/eslint-plugin/tree/master/rules/no-getState

• Matching with methodology (layers/slices/segments/grouping/ ...)
• kebab-case / PascalCase / camelCase?

Description

• Process order of imports
• For each layer
  (app > processes > pages > widgets > features > entities > shared)
• (If possible) with tests

// Fail
import { getSmth } from "./lib";
import axios from "axios";
import { data } from "../fixtures";
import { authModel } from "entities/auth";
import { Button } from "shared/ui";
import { LoginForm } from "features/login-form";
import { Header } from "widgets/header";
import { debounce } from "shared/lib/fp";

// Pass
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 { 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

Reference

Description

Линтер не видит ошибки в данном кейсе

import { Something } from 'feature/some/ui';

filePath: "feature/some/ui.tsx"

Reference:

#50

https://github.com/sverweij/dependency-cruiser

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 #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?

Description

• Add some integration tests for global config
  Should check, that every unit-config works correctly without affecting
  • Restrict imports between layers (lower imports higher)
  • Restrict imports between slices (slice import another on the same layer)
  • Restrict private imports (segments access)
• (If need) Clean unit-configs from redundant base-fields
  #32 (comment)

Description

• Segments (in shared and in slices) should follow the next rule:

  ui => model => api => lib => config

• Ideally:

  [ANY_CUSTOM_SEGMENT] => ui => model => api => lib => config => [ANY_CUSTOM_SEGMENT]

#55 (reply in thread)

Example

/** @path features/smth/ui/** */
// Pass
export { getSmth } from "../lib";
export { selectById } from "../../model";

/** @path features/smth/api/** */
// Fail
export { FormType } from "../../../ui";
export { selectById } from "../../model";
// Pass
export { getSmth } from "../lib";