chore(deps): upgrade minimatch to v10.2.4

[dargmuesli]

Resolves GHSA-3ppc-4f35-3m26
Resolves #206

cc @AndyBitz in relation to vercel/serve#842! 🙌

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	minimatch@​10.2.4

View full report

[rsahrakorpi-cambri]

Hey — just a heads up that this version bump alone will break at runtime. minimatch v10 changed its export shape: require('minimatch') now returns an object instead of a function.

TypeError: minimatch is not a function
at sourceMatches (serve-handler/src/index.js:59:17)

The import on line 10 of src/index.js needs to be updated:

-const minimatch = require('minimatch');
+const {minimatch} = require('minimatch');

[MikeMcC399]

Hey — just a heads up that this version bump alone will break at runtime. minimatch v10 changed its export shape: require('minimatch') now returns an object instead of a function.

TypeError: minimatch is not a function at sourceMatches (serve-handler/src/index.js:59:17)

The import on line 10 of src/index.js needs to be updated:

-const minimatch = require('minimatch'); +const {minimatch} = require('minimatch');

Simulating CI tests.yaml would also fail without this change:

yarn install --network-timeout 1000000 --frozen-lockfile
yarn run build-views
yarn test

[MikeMcC399]

#228 has proposed a simpler resolution

[MikeMcC399]

Since this repo does not appear to use an automated release process, then it probably doesn't matter that the commit message uses "chore(deps):". If it were automated, then it would need to be fix(deps):.

[dargmuesli]

I've applied the patch proposed by @rsahrakorpi-cambri 🙌

[AndyBitz]

Thank you for opening this PR!

I'll publish a new version as soon as possible. 

After some consideration, I think it's better to go with #228 to stay within 3.x.

Upgrading to 10.x would warrant a major release which is less ideal in this case for a security fix.

[dargmuesli]

@AndyBitz what do you think about introducing a caret version range for dependencies? Pinned dependency version can stay for devDependencies of course. Allowing minor and patch updates for dependents would remove the need to spend the time on maintenance required by this, my last and similar pull requests. Easing things on your part if nothing speaks against it.

[AndyBitz]

@AndyBitz what do you think about introducing a caret version range for dependencies? Pinned dependency version can stay for devDependencies of course. Allowing minor and patch updates for dependents would remove the need to spend the time on maintenance required by this, my last and similar pull requests. Easing things on your part if nothing speaks against it.

Sounds great! I think historically we would have preferred pinned versions to ensure there aren't any differences between any two installed versions, well, as one of many reasons, but maintenance wise I think it does make sense to go that route.

[dargmuesli]

@AndyBitz here we go! 🚀 ➡️ #229