feat: add matchesGlob export

[pi0]

resolves #182

Add matchesGlob export to match latest node:path and stay as drop-in replacement (docs)

The implementation uses vendored+minified version of minimatch to be the same as Node.js zeptomatch. (ESM + CJS + tree-shakable + lazy evaluated)

• Diff: +2.7 kB (+34.6%) (packed) / +11.6 kB (+28.6%) unpacked
• Comparation: node_modules/.pnpm/zeptomatch@2.0.0 +236K / +37 files packagephobia
• Diff: + 19.4 kB (packed esm+cjs) / +43.1 kB (unpacked esm+cjs) / +0 files
• Comparison .pnpm/minimatch@10.0.1: + 572 kB / +60 files

[danielroe]

I would suggest that we omit implementing this feature due to the increase in size.

[pi0]

other than node:path compatiblity, Alternative way to use glob in other projects is another dependency and both micro/picomatch are way bigger in all terms, cjs and even non treeshakable. pathe is only standard place i could think we can ship optimized glob util.

[danielroe]

did you come across/evaluate zeptomatch?

another option might be refactoring and including in glob-native?

[danielroe]

could we add it as a dependency rather than bundling it?

[pi0]

Amazing suggestion. Brace compatibility is limited but I think bundle size worth it. (bundled version is dual format, lazy eval similar to Node and much smaller) packagephobia

[danielroe]

Not bundling does mean it can deduplicate across other deps though, which I would prefer in honesty. (if even one other dep uses zepto then we lose any size benefit)

[pi0]

It is a common practice i do within unjs (consola, jiti, confbox, jimp-compact. …) when there is benefit it is not an exception here.

And i prefer we do this here too (there are clear stats it is not preference only btw). Without bundling we could even use minimatch end result is not much different!

Vite, Next.js and Nuxi also do bundling btw for similar reasons.

[pi0]

external dep is also not lazy evaluatable in (non async) ESM context, thats a runtime overhead it imposes for basically every pathe consumer even if they don’t use glob functionality.

[danielroe]

unless necessary I think it's a negative to inline or bundle dependencies that could otherwise be deduped. vite and nextjs are frameworks rather than libraries, and nuxi is single file executable. (all three are special cases for me).

I would cast a vote against it, particularly given there is no essential reason to add this utility to pathe rather than just depending on zeptomatch in any project that needs the functionality.

[pi0]

Appreciate your time and sharing feedback ❤️ Adopting zeptomatch was a really great suggestion.

I understand the difference between libraries and frameworks, I made some + unjs tools are their building blocks :) consola, jiti and confbox are obvious examples (of libs) that bundling sub-deps helped (I let you to calculate how much traffic and disk space/access over years they saved and judge for them).

So far, non of zeptomatch dependents overlap with our ecosystem (pathe users in particular) so externalizing (other than in theory) does not benefits any of pathe users.

For this PR, bundling benefits are:

• Dual format (ESM/CJS) support
• Zero runtime (eval) overhead for any of pathe users not using glob
• -220 kb install size / -37 files / -2 (I guess *2 for meta) network calls in fresh install to resolve subdeps.

(externalization has an opposite effect!)

particularly given there is no essential reason to add this utility to pathe

Glob is an essential functionality in many usecases -- common enough that Node.js also added it to the core. Using zeptomatch is just an implementation detail here and could change. and pathe is portable / runtime-independent node:path alternative. -- please consider, there was no reason to have anything in the entire UnJS ecosystem if we said, there is another alternative, pathe itself also wouldn't need to exist.

[danielroe]

personally I don't consider zero dependency to be a benefit for a library like pathe, if we achieve it by inlining those dependencies (though I do see your metrics and understand the slight benefit)

I would rather use another purpose built library like zepto (or something else), and advocate using it across ecosystem where required rather than suggesting people use our inlined version instead (this is a philosophical point as well as one about deduplication/total size)

if there is any problem with that library, such as in its packaging, I'm sure the maintainer would be delighted to improve it

[pi0]

pathe is a single standard path util, usable consistently across UnJS ecosystem and glob support is a missing feature from it today. If we change details (zeptomatch) to something else in the future, pathe is still canonical place to provide backward compat, warns, etc.

I have provided as much reasons and explanations as could above that judges the decision by facts and hope even if today you can't agree, see it better in the future.

[danielroe]

no worries.

I appreciate you valued my opinion, which remains that we should not inline this from another library.

(not inlining it does not stop pathe having canonical behaviour or prevent us from swapping implementation later)

I am not attempting to block you, just passing on my considered opinion 🙏

[pi0]

Inlining in this case has clear benefits over externalization (#195 (comment)) and dedup point is not relevant (at last today) -- nothing philosophical. If we come to the fact that externalization has more benefits at some point, I'm 💯 open to changing dep as external (and we actually did switch between inline<>external in several cases before in UnJS)

Advising to depend on pathe as canonical glob util instead of (various) choices is an ecosystem goal of UnJS to unify.

[danielroe]

i think there is a misunderstanding. i mean deduping zeptomatch itself, not its dependencies

[pi0]

I pointed to Dependents page not Dependencies.

[danielroe]

oh, my misunderstanding. it may change in future as it is adopted