loeffel-io / ls-lint

An extremely fast directory and filename linter - Bring some structure to your project filesystem
https://ls-lint.org
MIT License
1.73k stars 32 forks source link

Behavior when matching multiple patterns #161

Closed ethanjdiamond closed 4 months ago

ethanjdiamond commented 11 months ago

Hi! I hit some behavior I wouldn't expect, and was wondering if it was on purpose.

My scenario is that I want 1) all of my .svelte files to be PascalCase and 2) all my .ts files to be camelCase, except in SvelteKit since SvelteKit route filenames are weird in that they sometimes start with a "+" (docs). <y initial instinct was to try to say ".ts is camelCase unless it's in a routes folder, and always .svelte PascalCase" was by using this configuration:

".ts": "camelCase"
".svelte": "PascalCase"
"**/routes/**":
    ".ts": "regex:\+?.*"

Unfortunately, in this scenario, the "/routes/" directory didn't inherit the general ".svelte" as I would have expected, so ".svelte" files go unchecked, but just under the "/routes/" folder.

The next thing I tried was to do a "catch-all", expecting that there'd be some precedence order for matching, like "first matching rule wins" or something:

"**":
     ".ts": "camelCase"
     ".svelte": "PascalCase"
"**/routes/**":
    ".ts": "regex:\+?.*"

In this scenario, it also didn't work because it checked against all matching directories. So "/routes/xxxxxx.ts" gets checked against both the "camelCase" and the "regex:+?.*" rules. Nothing ever succeeds because there's no filename that matches both.

I finally settled on doing the first config, and copying the ".svelte": "PascalCase" rule under routes directory as well, but it seems redundant:

".ts": "camelCase"
".svelte": "PascalCase"
"**/routes/**":
    ".ts": "regex:\+?.*"
     ".svelte": "PascalCase"

Are both of those behaviors intended? Both seem counterintuitive to me.

loeffel-io commented 11 months ago

Hey @ethanjdiamond

thanks for your report - to see this in action, can you please provide a sample directory for me with configurations? That would help a lot

Thanks

loeffel-io commented 11 months ago

Btw: v2.2.0 includes a new debug system where you can find all the computed indexes

I am pretty sure this could belong to the order of the directories

ethanjdiamond commented 10 months ago

Sorry, didn't see the notification for this response. I'll send over a repo when I get home.

ethanjdiamond commented 10 months ago

Just went to recreate this, and I think I was mistaken on the So "/routes/xxxxxx.ts" gets checked against both the "camelCase" and the "regex:+?.*" rules part. I think my **/routes/** was supposed to be **/routes because it was causing things at the root of /routes not to match. Sorry for the confusion!

It would still be nice to have a way of specifying global rules instead of restating them inside each directory. In this repo, neither of the ls-lint configs catch the shouldGetCaught.svelte file not being kebab-case. I understand this behavior may be intentional, but it would be nice if there was a way to do a cascading global rule. To make the sample project catch the shouldGetCaught.svelte I'd need to do this:

ls:
  .ts: kebab-case
  .svelte: kebab-case
  'src/inner':
    .ts: regex:\+[a-z]+(-[a-z]+)*
    .svelte: kebab-case // This feels redundant. Why doesn't the outer .svelte definition cascade so I don't need to write this?
loeffel-io commented 5 months ago

Hey @ethanjdiamond,

now i understand - this was a design decision. The goal of ls-lint is simplicity first - for instance, if the specifications are very deep, its not instant clear which rules are applied imo