Using eslint-plugin-project-structure to automate FSD project structure review

[Igorkowalski94]

Hey, I think you might be interested in my new eslint plugin. You can fully automate the review of project structure rules for FSD and make it available to the community.

eslint‑plugin-project‑structure

ESLint plugin with rules to help you achieve a scalable, consistent, and well-structured project.

Create your own framework! Define your folder structure, advanced naming conventions, file composition, and create independent modules.

Take your project to the next level and save time by automating the review of key principles of a healthy project!

project‑structure/​folder‑structure

Enforce rules on folder structure to keep your project consistent, orderly and well thought out.

Features:

• Validation of folder structure. Any files/folders outside the structure will be considered an error.
• File/Folder name regex validation with features like wildcard * and treating . as a character, along with other conveniences.
• Build in case validation.
• Inheriting the folder's name. The file/folder inherits the name of the folder in which it is located. Option of adding your own prefixes/suffixes or changing the case.
• Enforcing the existence of a files/folders when a specific file/folder exists. For example, if ./src/Component.tsx exists, then ./src/Component.test.tsx and ./src/stories/Component.stories.tsx must also exist.
• Reusable rules for folder structures.
• An option to create a separate configuration file with TypeScript support.
• Forcing a nested/flat structure for a given folder.
• Support for all file extensions.
• Folder recursion. You can repeatedly nest a folder structure and set a limit on the nesting depth. There is also an option to change the rule at the final level, such as flattening the folder structure.
• Fewer repetitions and precise error messages, even for deeply nested folders (recursion), by representing the folder structure as a tree.
• Checking the length of paths and notifying when the limit is exceeded.

project‑structure/​independent‑modules

A key principle of a healthy project is to prevent the creation of a massive dependency tree, where removing or editing one feature triggers a chain reaction that impacts the entire project.

Create independent modules to keep your project scalable and easy to maintain. Get rid of dependencies between modules and create truly independent functionalities.

Features:

• Creating independent modules in which you control what can be imported (e.g. types, functions, components of one functionality cannot be imported into another functionality).
• The ability to create very detailed rules, even for nested folder structures. Whether it's a large module, a sub-module, or a single file, there are no limitations.
• Disabling external imports (node_modules) for a given module (Option to add exceptions).
• Non-relative/relative imports support.
• Support for imports without extension.
• Reusable import patterns.
• Support for path aliases. The plugin will automatically detect your tsconfig.json and use your settings. There is also an option to enter them manually.
• An option to create a separate configuration file with TypeScript support.

project‑structure/​file‑composition

Enforce advanced naming rules and prohibit the use of given selectors in a given file.

Have full control over what your file can contain and the naming conventions it must follow.

Features:

• File composition validation.
• Supported selectors: class, function, arrowFunction, type, interface, enum, variable, variableCallExpression, variableTaggedTemplateExpression.
• Rules for exported selectors, selectors in the root of the file and nested/all selectors in the file. They can be used together in combination.
• Prohibit the use of given selectors in a given file. For example, **/*.consts.ts files can only contain variables, **/*.types.ts files can only contain enums, interfaces and types.
• Enforcing a maximum of one main function/class per file.
• Inheriting the filename as the selector name. Option to add your own prefixes/suffixes, change the case, or remove parts of the filename.
• Selector name regex validation.
• Build in case validation.
• Different rules for different files.
• An option to create a separate configuration file with TypeScript support.

[illright]

Hey Igor, interesting project! Does it support restriction on imports, or are there plans to support that? This would be the most important thing to check automatically when considering the validity of an FSD project.

As for creating a structure for FSD, I'm not sure that would be possible or very useful, since FSD doesn't impose any restrictions on file names or on positions of the FSD roots in your project. For example, all of these are valid FSD:

src app pages shared

packages package1 app shared widgets package2 entities features widgets

app entities features pages routes

With segments there are also not many restrictions, you can use the standard ui, model, api, or you can create your own and still be valid in terms of FSD. So the concept of an FSD project is quite fluid, and one project can be vastly different from another, as long as some of the most important rules are satisfied.

[Igorkowalski94]

The idea of ​​this plugin is rather to validate rules regarding project structure, naming and extensions and automate the review of these rules, which is also an important element of a clean repository. From what I understand, FSD has quite specific "layers" that can be validated. Each of them may have different variations in terms of naming, but in general, a project based on FSD has a quite extensive structure that is worth validating. That's why I think it quite fits the spirit of the FSD community.

[illright]

Yeah, layers in FSD are the most standardized, but layers can be anywhere in the repository, not necessarily src. I'm not sure if your library supports "plug-in" structures that people would be able to customize in their own projects.

The only other thing I think is worth validating is that there are no loose files in layers, files that are outside of slices. But again, I'm not sure how to encode that in the configuration given the problem I stated before.

[Igorkowalski94]

I don't really understand why you assume you can only create rules for src folder. There are no limits, you can validate even the entire monorepo, with any folder name. Here's an example.

As I said earlier, if someone creates a base structure for FSD, I can add it as a ready-to-use example. Then it can be modified to suit the needs of a given project. You can create such examples for different frameworks.

Generally, I am a supporter of standardizing project structures for a given framework. In this case, the transition from one project to another will be much easier. My plugin allows you to easily implement such a standard. People will be able to use ready-made, well-thought-out configurations for a given framework.

The only other thing I think is worth validating is that there are no loose files in layers, files that are outside of slices. But again, I'm not sure how to encode that in the configuration given the problem I stated before.

You can create such a rule. For a given folder, you can force only folders/files with a given name/extension.

Try to create some rules for your project. Then you will see all the possibilities. If you have any problems/questions, feel free to write here ;p

[Igorkowalski94]

Hey, there’s a big update regarding this discussion. The plugin now provides full support for restricting imports and creating independent modules, along with the ability to create an advanced folder structure and naming conventions. I think this might interest you.

[illright]

That is interesting indeed, but since then, we announced our own linter called Steiger, which is now the official way of checking compliance with the rules of FSD. However, some people still prefer to use ESLint, so if you could make an easy-to-integrate preset for FSD, we'd be glad to feature it in our Awesome list