Group capture

[ratierd]

Hi ! Thanks for creating this tool. Me and my team would like to use this project to enforce a rule so that every file in a given folder would be named after the folder name.

In order to have something like this :

• folder
  • index.ts // Allowed
  • folder.view.ts // Allowed
  • folder.hooks.ts // Allowed
  • folder.specs.ts // Allowed
  • foo.ts // Forbidden

I've created this PR in order to achieve this but I think the feature could be used in other scenarios.

It relies on micromatch capture feature which allows to identify group in the glob. I then use it in the rule using a special syntax $index referring to a given capture group.

[dukeluo]

@ratierd Thanks for your pull request. Group capture is a great idea, it's very useful for rule filename-naming-convention.

[dukeluo]

Each ruleTester should always have the same options in this project. I noticed there are different options in this ruleTest.

Please let me know if you have any questions or concerns.

[dukeluo]

As shown in this test case and the one above, ignoreMiddleExtensions seems cant work well now.

[dukeluo]

I really like the idea of group capture. Thank you for your contribution to this project. I have gone through your pull request and I do have a few concerns that I would like to address:

1. Regarding the ignoreIndexFiles parameter, I think we can exclude the index file using the glob expression instead of introducing a new parameter.

2. I noticed the use of $1* in the code, and I was wondering about its meaning and how it differs from $1. Is $1 enough?

3. We use $ to indicate our custom syntax, but what if we need to include a $ in a glob expression? How do we handle this case?

Please let me know if you have any questions or if there is anything I can do to assist you in addressing these concerns.

[ratierd]

I really like the idea of group capture. Thank you for your contribution to this project. I have gone through your pull request and I do have a few concerns that I would like to address:

1. Regarding the ignoreIndexFiles parameter, I think we can exclude the index file using the glob expression instead of introducing a new parameter.
2. I noticed the use of $1* in the code, and I was wondering about its meaning and how it differs from $1. Is $1 enough?
3. We use $ to indicate our custom syntax, but what if we need to include a $ in a glob expression? How do we handle this case?

Please let me know if you have any questions or if there is anything I can do to assist you in addressing these concerns.

1. Yes I thought so, I replaced it with something more generic, ignorePattern. Leveraging the ignore API of micromatch
2. I tried to avoid having the extra * but it throws an error There is an invalid pattern "featureA", please check it since it is not a glob or a builtin pattern
3. I didn't think about that. I updated the syntax to be <index> instead. Since angle brackets are illegal in Windows filename and isn't a glob special character it should be safe

[codecov]

Codecov Report

Merging #17 (5c05dbc) into main (8369b6f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##              main       #17   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        11    +1     
  Lines          156       174   +18     
=========================================
+ Hits           156       174   +18     

Impacted Files	Coverage Δ
lib/rules/filename-naming-convention.js	100.00% <100.00%> (ø)
lib/utils/settings.js	100.00% <100.00%> (ø)
lib/utils/transform.js	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[dukeluo]

There is no necessary to introduce a new parameter ignorePattern, you can use a glob expression like src/*/!(index).* to select target files. see more

[ratierd]

Okey, yes it's even better . Thanks

[dukeluo]

You get a error an error There is an invalid pattern "featureA", please check it since it is not a glob or a builtin pattern since you transform custom syntax firstly and then run into the checkSettings validation function. In this case, <1> will be featureA, but featureA is not a valid pattern.

I have an idea, we only allow three kinds of pattern styles for this rule: builtin pattern, glob pattern and our group capture syntax(<index> or $index). We only allow user choose one style at one time, and dont allow mix with them. So in this way, <1>*, CAMEL_CASE* both are illegal.

I feel like this would reduce the complexity, and make it more clear and easy to use.

[ratierd]

Yes it seems like a good idea.

I think I got most of it down but I can't figure out what part of the coverage I'm missing.
I use sonar in some other projects to see which lines specifically aren't covered.
Do you use something similar ?

[dukeluo]

Yes it seems like a good idea.

I think I got most of it down but I can't figure out what part of the coverage I'm missing. I use sonar in some other projects to see which lines specifically aren't covered. Do you use something similar ?

Check out this link.

[dukeluo]

Cool, looks good to me. Thanks for your PR. It will be released in next version.

[dukeluo]

This PR has been released.