1.0.0 roadmap

Open
#178 1 comment 7 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
node.js, typescript
Domain
tooling

Research direction

No files, tests, or entry points are named. Start by reviewing the proposed 1.0.0 changes and their Node.js, ESM, dependency, and compatibility implications. This roadmap needs a concrete proposal selected and scoped before implementation can have a defined done state.

Written by the indexing model from the issue text.

Description

still likely not happening anytime soon, just leaving future plans here to gather thoughts:

plan is to make 1.0.0 as full of major changes as possible to ideally never have to release a major version again

  • removal of deprecated patterns option
  • make expandDirectories default to false (considering, unsure, would involve MOST users changing their code to maintain the same behavior, would make it less compatible with globby by default but more compatible with fast-glob)
  • switch to esm (would half package size, users on old node versions could still use 0.x which id try to still maintain)
    • would this involve upping engines range? not sure. ideally would be >=20.19.0 or something like that for require-esm
    • to avoid people migrating back to fast-glob this could wait until fast-glob goes esm-only. i've seen it's planned for 5.0.0. it's not even at 4.0.0 yet so it might take a while
  • switch to zeptomatch. would need switching to esm
    • this would be great since it's faster than picomatch, smaller and actively maintained. picomatch also has some longstanding bugs
    • downside: it's two dependencies instead of none. considering node-glob just got to 6 dependencies i really don't want to increase the number of dependencies to remain competitive
  • should ignore stop taking strings? every other library only takes string[]s

super future potential plans (2.0.0 or something like that, might never happen)

  • go zero dependency and use fs.glob and path.matchesGlob
    • they both currently use minimatch under the hood which is slow. would need node to make it more performant. itd be cool if they moved the implementation to c++
    • would need a huge engines increase (id be most comfortable with >=24). if this ever happens enough time would have passed for it to be a common engine range
    • the point of tinyglobby would then be for those who can't migrate to fs.glob due to needing the same api and behavior as globby/fast-glob
Dominant language
TypeScript
Stars
544
Forks
30
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SuperchupuDev/tinyglobby

All issues in SuperchupuDev/tinyglobby

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.