Rules for directory names

[markalfred]

This is a feature I would personally use, but not sure if there's any demand for it from other folks or if it's better off as its own plugin.

For instance, I want all files and directories to be kebab-cased so that there are no issues between case-insensitive (OSX dev environments) and case-sensitive (Linux deployment environments). Currently, though, with this configuration:

"filenames/match-regex": [2, "^(-|[a-z])+$"],

I could create this file with no problem:

app/Components/Auth/auth-header.jsx

On my OSX machine, I could import AuthHeader from 'app/components/auth/auth-header' with no problem.

But as soon as I deploy to a linux environment... 💥

[AndersDJohnson]

@selaux @markalfred I would love this feature as well. For backwards compatibility, maybe enable as an option to filenames/match-regex to match full file paths instead of just base file names?

Not sure if we should try to trim the absolute paths to be relative to the project root - may be tricky.

Would you accept a pull request and consider a release, or is it not worth my time?

[selaux]

@AndersDJohnson Sure, I would gladly accept a PR. match-regex could be extended to match each path segment relative to root. Not sure how to find the root though 😉

[vhlongon]

Hi @selaux I am working on this but I am not sure how to set the root folder in my tests. I have a failing test now that should pass:

{
            code: testCode,
            filename: "SomeDir/VariableName.js",
            // parserOptions: { ecmaVersion: 6, sourceType: "module" },
            options: ['pascal']
        },

The Dirname returned is foo/SomeDir where it should be Foo/SomeDir, but I am not sure how to set foo to Foo

[vhlongon]

How can I change which root folder is sent? It should differ to match-dirname tests, since I don't want /fooas in the other tests.

[selaux]

Can you upload the code, so I can have a look at it? I don't fully understand the question yet...

[fsmaia]

I would love to contribute to it too. I have developed a rule enforcing a custom file structure, but it could be easily adjusted.

[Xooone47]

I would love to contribute to it too. I have developed a rule enforcing a custom file structure, but it could be easily adjusted.

what about your rules now?

[fsmaia]

As it is small, I will post its entire code here.

Keep in mind that is was developed for an opinionated file structure (feature-based with layers inside of the features).

module.exports = {
  meta: {
    docs: {
      description: 'This rule enforces a file path to match the guideline',
      recommended: true,
    },
    messages: {
      [MATCH_PATH_MESSAGE]: "File path '{{ pathDir }}' should match the guideline",
    },
  },

  create: (context) => {
    //----------------------------------------------------------------------
    // Public
    //----------------------------------------------------------------------
    const joinOptions = (options) => `(${options.join('|')})`;

    return {
      Program: (node) => {
        const filename = path.resolve(context.getFilename()).replace(/\\/g, '/');
        const rootFile = joinOptions(['serviceWorker', 'store']);

        const validFiles = [
          `${SRC_FOLDER}/${rootFile}.(js|ts)`, // src root files
          `${SRC_FOLDER}/index((.integration)?.test)?.(js|ts|tsx)`, // src root file
          `${SRC_FOLDER}/router.(js|tsx)`, // root router file
          `${SRC_FOLDER}/modules/index.(js|ts)`, // modules entrypoint
          `${SRC_FOLDER}/${I18N_LAYER_FOLDER}/${I18N_CASE}.json`,
          `${FEATURE_FOLDER}(/${LAYER_FOLDER})?/index((.integration)?.test)?.(js|ts)`, // entrypoints
          `${FEATURE_FOLDER}/${NAMESPACED_LAYER_FOLDER}(/${KEBAB_CASE})?/index(.test)?.(js|ts)`,
          `${FEATURE_FOLDER}/${LAYERS.DECORATORS}(/${KEBAB_CASE})?/index(.test)?.tsx`, // decorators may have JSX
          `${FEATURE_FOLDER}/${CONSTANTS_LAYER_FOLDER}/${KEBAB_CASE}.(js|ts)`,
          `${FEATURE_FOLDER}/${REACT_LAYER_FOLDER}(/${PASCAL_CASE})?/index.scss`,
          `${FEATURE_FOLDER}/${REACT_LAYER_FOLDER}(/${PASCAL_CASE})?/index((.integration)?.test|.story)?.(js|tsx)`,
          `${FEATURE_FOLDER}/${TYPESCRIPT_LAYER_FOLDER}/${PASCAL_CASE}.ts`,
          `${FEATURE_FOLDER}/${FREESTYLE_LAYER_FOLDER}.*`,
        ];

        const validFilesRegExp = new RegExp(`${joinOptions(validFiles)}$`);
        const fileIndex = filename.indexOf('src');

        if (filename.match('src') && !filename.match(validFilesRegExp)) {
          context.report({
            node,
            messageId: MATCH_PATH_MESSAGE,
            data: { pathDir: filename.slice(fileIndex) },
          });
        }
      },
    };
  },
};

[YuriiBoikoOpn]

also will be great to have similar rule for folders, as you have for files: filename-case

[Igorkowalski94]

As an alternative, you can use eslint-plugin-project-structure

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 nest a given folder structure recursively. - Fewer repetitions and precise error messages, even for deeply nested folders (recursion), by representing the folder structure as a tree.

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/​naming‑rules

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:

- Naming validation. - Supported selectors: `class`, `variable`, `function`, `arrowFunction`, `type`, `interface`, `enum`. - Naming 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. - Inheriting the filename as the selector name. Option to add your own prefixes/suffixes, change the case, or remove parts of the filename. - Enforcing a maximum of one main function/class per file. - Different name rules for different files. - Regex validation. - Build in case validation. - An option to create a separate configuration file with TypeScript support.