Wildcard support for file extensions?

[Nicolas Reibnitz]

Hi!

First of all, I'd like to say that I love this! Exactly what I was looking for! Thanks!

One feature that seems to be missing (or would be great to have) is the option to set a general rule for all files. Specifically to say that all files and folders should be lowercase, regardless of their extension.

It seems that something like this isn't possible:

ls:
    .*: lowercase
    .dir: kebab-case
    .js: kebab-case
    ...

Correct?

The alternative would be to find out what extensions are in a project and what extensions could come up in the future, which isn't really feasible.

Or do you have another idea?

Thanks in advance!

P.S. One could, of course, run something like this to find all files and folders that have uppercase letters in them:

find . -path ./node_modules -prune -false -o -name "*[[:upper:]]*"

But depending on the number of folders to ignore, this can quickly get pretty messy.

[Joe Gornick]

I've found myself wanting to use wildcards (i.e. glob) for other things like ignore paths as well. For examples I'd like to ignore **/node_modules. When I specify just node_modules, my first assumption was that whenever it runs across any file/directory located in any node_modules it'll ignore it, but node_modules just means the node_modules folder in the root where the configuration is.

Is it possible to use globs wherever matching needs to happen (e.g., extensions, paths, ignore)?

[Laurent Aphecetche]

Indeed, using a default rule for all files (possibly in a subdirectory) would be super helpful. My use case : checking that image files are all kebab case. Currently I cannot use ls-lint for that as for instance I don't know how to write a rule for don_t_like_this_name.JPG because it's the extension that is breaking the naming convention...

[Lucas Löffel]

Hey,

agree to all of you and i'll try to bring more and more glob patterns to ls-lint.

@aphecetche .JPG: kebeb-case isn't working?

[Laurent Aphecetche]

Hey,

agree to all of you and i'll try to bring more and more glob patterns to ls-lint.

@aphecetche .JPG: kebeb-case isn't working?

sorry for the late answer : no, it does not work (at least for what I want to do, I.e. have the full filename be kebab-case), as the casing of the extension itself is not checked as far as I can tell.

[Dominic Beinenz]

Wildcard support would be perfect (but not only for ignores)
I plan to define a regexp to forbid some file-extensions

ls:
  
  components/assets:
    .dir: kebab-case
    .png: kebab-case
    .*: regex:only-png-files-allowed

[tigerinus]

wildcard support, or default rule, please

[Mathias Schreck]

I think this would be also useful for files without extensions. For example binary/executable files are often without extension.

[Ethan Diamond]

Love the library! Thanks for making it.

I'm going to add another use case for this that I've run into, which is sub-extensions. My app uses SvelteKit and Vite, which means I'm dealing with .d.ts, .config.ts, .server.ts. For all of those I want camelCase for the base name and would love to be able to do .*.ts: camelcase instead of individually calling out all those sub-extensions.

[Lucas Löffel]

Hey folks, lucas here, creator of ls-lint

i really could need your help ❤️

i implemented the wildcard support and it will be possible to do all kind of specifications (until infinity), for instance:

.*
.*.*
.service.*
.*.js
.*.*.*
...

now the question is - do i lookup rules from left to right or right to left, for instance:

left to right

camelCase.service.gif

ls:
    .service.*: camelCase # this rule would be applied for camelCase.service.gif
    .*.gif: PascalCase
    .*.*: snake_case # will always be the latest fallback

right to left

camelCase.service.gif

ls:
    .service.*: camelCase
    .*.gif: PascalCase # this rule would be applied for camelCase.service.gif and fails
    .*.*: snake_case # will always be the latest fallback

would love to get some contributions for this 🙏

[Ethan Diamond]

@loeffel-io Honestly, neither. I would have expected it to go top to bottom, and check against the first match. So if .service.* was first in the list under ls:, I'd expect the file to be checked for camelCase, and if you moved .*.gif to be the first rule, I'd expect the file to be checked for PascalCase.

[Lucas Löffel]

@ethanjdiamond, thank you for the contribution 🙏 i think this would kill some of the simplicity ls-lint is driven for. the yaml file is is map data structure which is firstly unordered - i will think about this