Refactor GlobOptions to center option processing. - #170
Conversation
commit: |
|
do we really need to manually validate the function type? doesn't typescript reject non-functions already? also you can delete the additionally, i think doing |
I don't know the structure of
Good point, but I have to see how I have to handle that as some falsy values are still set as undefined. If I use |
|
New metrics: Total Shipped Size: Which is now a decrease of |
|
i'm trying to think if there's any other way to write the new types with less duplication, but other than that lgtm |
|
That's the thing. I don't like the way this is written either. If you could just do: export interface InternalGlobOptions extends Required<GlobOptions> {
declare absolute: boolean
}Then it would be fine. The other way I can think of now is to create a common subset type export type InternalOptions = GlobOptions & Required<InputOptions>But I'm not sure how this would change the generated types. |
|
Since I didn't receive any feedback on that idea, I implemented for review. This should be cleaner and every property is now documented when hovered over, but increases the output bundle: Also, I managed to find another size reduction in Total Shipped Size: Which is now a decrease of |
|
sorry, i didn't notice your past comment. i'll take a look in a bit! |
|
Yeah, this reduced the types back to Total Shipped Size: Which is now a decrease of |
SuperchupuDev
left a comment
There was a problem hiding this comment.
looks a lot better now, thank you! one more thing and this should be ready to merge
| debug: !!process.env.TINYGLOBBY_DEBUG, | ||
| expandDirectories: true, | ||
| followSymbolicLinks: true, | ||
| fs: nativeFs, |
There was a problem hiding this comment.
i have no perf metrics regarding fs imports and it wouldn't really affect tinyglobby performance, but wouldn't this be too expensive since it would have to import every export of the fs module? also would likely make tree-shaking harder
There was a problem hiding this comment.
That's hard to answer question what tree-shakes better. After scouring through Node.JS docs and reading a few articles, I still don't have a clear answer, but your method is technically more tree-shakable than my method. The main performance impact comes from the extra start-up time, which will be less the deeper it is integrated into another tools also importing node:fs.
Since tree-shaking happens during source-code parsing, I don't think either of our methods would make it entirely tree-shakable, since it is uncertain wether or not options.fs is set or not, but your method only restricts itself to those 6 functions, which makes it more efficient.
I think the best method of ensuring we only import the things we need and tree-shake the rest, as node built-in modules are almost always treated as external packages, is to use destructured imports:
import { readdir, readdirSync, realpath, realpathSync, stat, statSync } from 'node:fs'
const DefaultFS = { readdir, readdirSync, realpath, realpathSync, stat, statSync }
But since tinyglobby is more like a core utility in huge node.js tools, the overall effect would be minimal either way.
|
If there is anything else that needs to be done, instruct me what I should change. From my part, it looks fine and we can wrap this up, so I can move to the next split part of the original PR. |
|
i haven't been doing much code stuff the last few weeks, but i'll let you know if you should change anything! |
There was a problem hiding this comment.
finally have some time to code and review stuff. all mostly looks good!! i think the only remaining thing to do is to refactor the nativeFs stuff to allow for tree-shaking. also, i've given it some thought and i think it'd be best if the fs option was left undefined by default, so that fdir can handle the default methods. the reason for this is future-proofing in case fdir starts using more fs methods. if we left this as-is and fdir did that, it'd be likely it would break usage of the library that doesn't use the fs option
|
I'm on board to say "nuke that shit!" and remove everything about it including Since the tests only test simple, partial overrides, I deleted them as well. Since we only propagate this option, I hope this won't affect coverage. |
|
Metrics of discarded commit: Total Shipped Size: Which is now a decrease of |
|
sadly, we need to keep our custom |
|
I've removed the commit that removed the fs handling and instead made it undefined by default. It actually removed like 20 bytes from the final shipped size, totaling at:
|
|
coverage lowered a bit, i think restoring the |
|
It seems like the attempt to revert the commit only partially worked or did nothing at all. I've added the tests back in. |
SuperchupuDev
left a comment
There was a problem hiding this comment.
thank you!! sorry for the wait

Goal
The goal of this PR is to center all internal processing of
GlobOptionsto one step of the program and make it type safe for the rest.Why
This change is necessary out of three reasons:
Currently, options are processed when needed, which cause multiple shape recalculations (more JS engine work) and can cause issues if steps need to be refactored. It improves code quality and readability.
What has changed
GlobOptionswith a truthy default value will now be injected into the options and validated with the user optionsGlobOptionshas been adjusted to assume those options with truthy values are always defined.globandglobSynchave been altered to now showPartial<GlobOtions>instead ofGlobOptionsInternal changes:
patternsAndOptionshas been changed toglobInputwith a new shortcut typeGlobInput.processPatternsandnormalizePatternhave been adjusted to avoid unnecessary property destructuring.normalizeCwdhas been inlinedMetrics
The bundle size has been reduced, but the gzipped size strangely shows an increase (maybe due to build target?)
Before:
After:
Total shipped size before:
14.22KB + 12.92KB + 4.7KB + 4.7KB = 36.54KBTotal shipped size after:
13.86KB + 12.55KB + 4.73KB + 4.73KB = 35.87KBThis is a bundle size reduction of 0.67KB (1.8%) and saves 22.1GB of weekly traffic.
This PR is a split part of the closed PR #88, which grew too much in scope and changes.