refactor: cleanup dependencies and reduce bundle size

[SuperchupuDev]

Replaces some bloated dependencies with well known alternatives that are both lighter and faster. @yao-pkg/pkg-fetch needs a cleanup too which I'll try to do if this PR gets accepted

• fs-extra - (3 dependencies) -> node:fs (native)
• globby@11 (23 dependencies) -> tinyglobby (2 dependencies)
• minimatch - (3 dependencies) -> picomatch (0 dependencies) which doesn't have catastrophic backtracking
• chalk@4 - (5 dependencies) -> picocolors (0 dependencies)

For more info on module replacements, check out https://github.com/es-tooling/module-replacements/tree/main/docs/modules, some more optimizations might be possible

Package size report: (using https://github.com/TheDevMinerTV/package-size-calculator)

Package info for "@yao-pkg/[email protected]": 9.9 MB
  Released: 2024-09-20 07:51:42.059 +0000 UTC (2w4d ago)
  Downloads last week: 5,284 (29.57%)
  Estimated traffic last week: 52 GB
  Subdependencies: 125

Removed dependencies:
  - [email protected]: 100 kB (1.00%)
    Downloads last week: 185,982,081 (N/A% from 4.1.2)
    Downloads last week from "@yao-pkg/[email protected]": 5,284 (N/A%)
    Traffic last week: N/A
    Traffic from "@yao-pkg/[email protected]": 52 GB (N/A%)
    Subdependencies: 5 (4%)
  - [email protected]: 191 kB (1.93%)
    Downloads last week: 20,426,745 (N/A% from 9.1.0)
    Downloads last week from "@yao-pkg/[email protected]": 5,284 (N/A%)
    Traffic last week: N/A
    Traffic from "@yao-pkg/[email protected]": 52 GB (N/A%)
    Subdependencies: 4 (3.2%)
  - [email protected]: 608 kB (6.13%)
    Downloads last week: 30,363,000 (N/A% from 11.1.0)
    Downloads last week from "@yao-pkg/[email protected]": 5,284 (N/A%)
    Traffic last week: N/A
    Traffic from "@yao-pkg/[email protected]": 52 GB (N/A%)
    Subdependencies: 23 (18.4%)
  - [email protected]: 455 kB (4.59%)
    Downloads last week: 8,219,537 (N/A% from 9.0.4)
    Downloads last week from "@yao-pkg/[email protected]": 5,284 (N/A%)
    Traffic last week: N/A
    Traffic from "@yao-pkg/[email protected]": 52 GB (N/A%)
    Subdependencies: 2 (1.6%)

Added dependencies:
  + [email protected]: 150 kB (1.51%)
    Downloads last week: 288,159 (N/A% from 0.2.9)
    Estimated traffic last week: N/A
    Subdependencies: 2 (1.6%)
  + [email protected]: 12 kB (0.11%)
    Downloads last week: 18,861,618 (N/A% from 1.1.0)
    Estimated traffic last week: N/A
    Subdependencies: 0 (0%)
  + [email protected]: 86 kB (0.86%)
    Downloads last week: 3,564,978 (N/A% from 4.0.2)
    Estimated traffic last week: N/A
    Subdependencies: 0 (0%)

Estimated new statistics:
  Package size: 9.9 MB → 8.8 MB (88.52%)
  Subdependencies: 125 → 102 (-23)
  Traffic with last week's downloads:
    For current version: 52 GB → 46 GB (6.0 GB saved)
    For all versions: 177 GB → 157 GB (20 GB saved)

[robertsLando]

@SuperchupuDev Thanks for your PR! I'm +1 for this, just please make test pass :)

[SuperchupuDev]

the test error seems to be because of a very specific tinyglobby edge case. i'll try to fix it there but meanwhile i've pushed a workaround in the test runner

[robertsLando]

@SuperchupuDev saw it but seems still not working

[SuperchupuDev]

yep, it looks like this new failure is related to picocolors's color support detection being different from chalk

[SuperchupuDev]

oddly, i can't reproduce the failure locally. maybe it's related to env variables set in CI?

[robertsLando]

@SuperchupuDev could it be because of nodejs version?

[SuperchupuDev]

i don't think so, i'm using node 20.17.0. i think i can manually set whether color support is enabled in picocolors though, and pass https://nodejs.org/api/tty.html#writestreamhascolorscount-env through it (which seems to use chalk's detection code https://github.com/nodejs/node/blob/54b5ec94e067650f72a680ea5bf6a84da36ea096/lib/internal/tty.js#L103-L105)

[SuperchupuDev]

i've used the implementation yoctocolors (which was made by a chalk member) uses https://github.com/sindresorhus/yoctocolors/blob/v2.1.1/base.js#L6. sadly we can't use that package as it's ESM only

[SuperchupuDev]

i can see that before my last commit i could get the tests to fail if i set CI=1 locally. just checked and this is no longer the case as of my last commit

[SuperchupuDev]

okay i have no idea why that fails. it seems to detect picocolors as a builtin module?

[robertsLando]

@SuperchupuDev Never seen such issue, it's really weird! That's happening when running a compiled binary, right? Seems like for some reason the compiled binary try to use picocolor that is a dep of pkg and that's happening on bootstrap.js file that is a file always loaded before executing binary code but seems you didn't touched prelude/bootstrap.js in your commit so sincerely I have no clue

[SuperchupuDev]

@robertsLando importing picocolors from anywhere other than common.ts makes it work for some reason, so i've made its own file for it at least until picocolors starts using node's hasColors api (alexeyraspopov/picocolors#85)

[robertsLando]

Yeah the reason is that common is imported in prelude/bootstrap, see https://github.com/yao-pkg/pkg/blob/main/prelude/bootstrap.js#L37

[robertsLando]

I think picocolors output something on console and this makes some tests fail as they rely on output

[SuperchupuDev]

if the reason the tests purposefully fail if they have colors is so output matching isn't buggy, i could easily set NO_COLOR in utils.pkg.sync which definitely disables them. is that okay?

[robertsLando]

@SuperchupuDev Ok try

[SuperchupuDev]

hi @robertsLando do you mind rerunning ci?

[robertsLando]

@SuperchupuDev I'm sorry I have been super busy, done now. Let's see how it goes 🤞🏼

[SuperchupuDev]

ok this is getting hard to debug, i'll just separate it into two or more prs

[SuperchupuDev]

@robertsLando i've separated this pr into #102 #103 #104 #105, one for each depencency change, so that one dep change breaking tests doesn't block the other ones