Fixed directory only pattern when using --only flag

[EvilGenius13]

This commit fixes an issue in the matchGlob to match directories when filtering through files

WHY are these changes introduced?

Closes: #4855

There was a bug in which passing a directory to the only flag would not work.
It turns out it wasn't working with the ignore flag either.

WHAT is this pull request doing?

Added some additional logic to the matchGlob method which looks for certain patterns. Now it also checks for folder structure patterns like assets/

Added tests for both only and ignore flags.

Example

Before:

CLI.broken.--only.mp4

After:

CLI.--only.fix.mp4

How to test your changes?

Pull down the branch
Build the branch
If in a directory with a theme:
- delete two different folders like assets and templates
- run shopify theme pull -t <your_thene> -o templates/
- You should only see the templates folder be synced
If in a blank directory:
- run shopify theme pull -t <your_theme> -o templates/
- You should only see the templates folder in your directory

Post-release steps

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
• Existing analytics will cater for this addition
• PR includes analytics changes to measure impact

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	75.33%	8890/11801
🟡	Branches	70.56% (-0.02% 🔻)	4322/6125
🟡	Functions	75.1%	2337/3112
🟡	Lines	75.87% (+0.01% 🔼)	8402/11074

Show files with reduced coverage 🔻

St.❔	File	Statements	Branches	Functions	Lines
🟢	... / app-event-watcher.ts	93.83% (-1.23% 🔻)	83.78% (-5.41% 🔻)	90.48%	98.61%

Test suite run success

2001 tests passing in 904 suites.

Report generated by 🧪jest coverage report action from c795653

[jamesmengo]

can you test this with templates/ to test a nested folder structure? I think it'll break

[jamesmengo]

🤔
Thanks for this change! I may be bike-shedding here, but I want to raise some thoughts I have about this approach.

The issue here arises because we don't have a strong glob contract.

• We're now using minimatch as our matching library after the TS rewrite
• For backwards compatibility reasons, we try to silently fix / replicate Ruby glob behaviour as a fallback [2]

My personal preference here is to diverge as little as possible from the JavaScript glob matching library moving forward.

I think we could render a warning to get the user to fix/remediate this issue rather than adding more custom behaviour.
ALTERNATIVELY, we can raise the warning / suggestion, but still fix it for them if needed by following the pattern laid out in [2].

As always, open to discussion and changing my mind!

[2]

• That's why we automatically substitute **/* here, since users already have globs that they're relying on.

We needed to do so because the Ruby library that we were previously using behaves differently than the javascript glob matcher 🤢