Open fsmaia opened 2 years ago
@fsmaia, Iβm not recommending my Rust spin-off version, but I allowed regex. Regex starts with a slash, so I could distinguish between glob and regex rules easily and didnβt mix them.
Beyond mentioning regex, I havenβt thought hard enough to have any concrete opinions on user experience yet. Regex is hard.
As an alternative, you can use 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!
Enforce rules on folder structure to keep your project consistent, orderly and well thought out.
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.
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.
@Igorkowalski94, itβs exciting that a repository seems to be getting traction to enforce folder structure. The keywords structure, children, rule, and name seem unwieldy though. Separating the config from eslint would aid readability too. I liked the simplicity of mine: https://github.com/mattferrin/folder-structure-lint
Perhaps you can use the traction you have to make simplifications that improve readability. Like having a list of simple string rules where every path in your source directory has to satisfy at least one. Itβs more legible that way, in my opinion.
@mattferrin
Separating the config from eslint would aid readability too.
The entire configuration is located in a separate file.
The keywords structure, children, rule, and name seem unwieldy though.
It's rather subjective, it's much easier to write rules for folder recursion this way and there is much less need to repeat yourself, from what I see in your package it's not possible, same as inheriting a name from a parent.
I'm curious what the following structure would look like in your package. There would probably be a lot of repetitions and I don't see how folder recursion would work...
For example, you have a folder containing many file/folder rules and you want to repeat it recursively:
π hooks
βββ ...
βββ π useSimpleGlobalHook.test.ts
βββ π useSimpleGlobalHook.ts
βββ π useComplexGlobalHook
βββ π hooks (recursion)
βββ π useComplexGlobalHook.api.ts
βββ π useComplexGlobalHook.types.ts
βββ π useComplexGlobalHook.test.ts
βββ π useComplexGlobalHook.ts
Also in my package you can mix Case with regex and parent name, here is an example.
And your package doesn't support eslint, so you can't see errors in real time.
@Igorkowalski94 Glob syntax allows for recursion so my tool does by extension. I probably didnβt demo it because I think itβs generally a bad idea.
Iβve never met 2 smart people that donβt disagree on something like that though. I valued simplicity so adding complex things to enforce complex things wasnβt aligned with my values. But I probably should have added support to enforce casing.
Beyond to
*
wildcards, it would be amazing to add naming convention restrictions, likecamelCase
,PascalCases
,kebab-case
,CONSTANT_CASE
, and others.This would be very useful for React components folders, for instance:
Maybe this could be achieved by accepting special patterns like:
[camelCase]
[PascalCase]
I'm super interested in helping and even implementing it if you will.