Skip to content

fs/path: expose internal-api minimatch/glob under path module. #40731

Description

@kaizhu256

Is your feature request related to a problem? Please describe.
Please describe the problem you are trying to solve.

i have a zero-dependency coverage-reporting-tool and would like to add a cli-option to exclude code-coverage based on file-glob-patterns, e.g.:

node jslint.mjs v8_coverage_report \
    --exclude=deps/*,test/* \
    npm run test

Describe the solution you'd like
Please describe the desired behavior.

expose ./deps/npm/node_modules/minimatch/minimatch.js under the builtin path module, e.g.:

import {minimatch} from "path";
minimatch("bar.foo", "*.foo") // true!
minimatch("bar.foo", "*.bar") // false!

Describe alternatives you've considered
Please describe alternative solutions or features you have considered.

i could re-implement ./deps/npm/node_modules/minimatch/minimatch.js into my zero-dependency-project, but i suspect there are many other projects out there that would benefit from exposing this api.

Activity

  1. moved this to Pending triage in Node.js feature requestson Feb 13, 2022
  2. isaacs commented on Feb 28, 2022

    @isaacs
    Contributor

    Update to this: I'm in the process of some updates to minimatch and glob to:

    1. Bring it into the modern era (classes, promises, iterating/streaming results, etc.)
    2. Improve performance and avoid ReDOS threats by just parsing and evaluating without building up massive regexps.
    3. Support some edge cases that have always been a problem (especially: nested extglob patterns).

    Once that's done, I'll be advocating for including it in core.

  3. github-actions commented on Aug 28, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  4. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Aug 28, 2022
  5. github-actions commented on Sep 28, 2022

    @github-actions
    Contributor

    There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  6. meyfa commented on Oct 9, 2022

    @meyfa
    Contributor

    I think this would be a great addition, still! Can this issue be re-opened?

  7. MoLow commented on Oct 29, 2022

    @MoLow
    Member

    @isaacs I intend to work on this.
    since your comment was posted 8 months ago can I assume you are not working on it as well?

  8. reopened this on Feb 19, 2023
  9. MoLow commented on Feb 19, 2023

    @MoLow
    Member

    I am re-opening this issue since:

    1. it was raised again Request: mark test runner stable in Node 20.0.0 #46642 (comment)
    2. mini-match seems to have had a major release lately

    @isaacs is this still true?

    Once that's done, I'll be advocating for including it in core.

  10. kaizhu256 commented on Feb 19, 2023

    @kaizhu256
    ContributorAuthor
    • just fyi, the original test-coverage-project that raised this issue been fixed (still would be a useful nodejs feature though)
    • here's standalone, 300-line-gistfile of minimatch-alternative i've been using to batch-glob large number of files for test-coverage
  11. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Feb 20, 2023
  12. isaacs commented on Apr 7, 2023

    @isaacs
    Contributor

    Yes, glob and minimatch have both been significantly updated lately. They're much faster, better designed, more faithfully implement bash pattern expansion semantics, and ship types.

    I'm still not sure it makes sense to pull into node core though. Making glob fast did require a lot of moving parts. But the license allows it, so have at it if y'all want it in. I see no reason to recommend otherwise, and would be happy to help out if someone attempts this and runs into issues.

    It might be desirable to make the glob stream interfaces node streams (or web streams) if so, as they're minipass streams to support sync globbing. It'll cost some perf to do that, tho. (Or we could talk about pulling in minipass, which wouldn't be a bad idea either, but that's of course a much bigger change.) Minimatch also exports its parser on minimatch.AST, which can be helpful if you want to use some parts but assemble it differently.

    If you only need a subset of the bash globbing behavior, and especially if you don't need hot path performance or windows support, then a couple hundred line js module can definitely suffice. But I would not recommend pulling such a glob subset into core, unless the node team is interested in a never ending stream of bug reports for every edge case where it'll diverge from shell behavior. Having an incorrect or incomplete glob module in core is arguably worse than not having one at all.

    Another completely different route to globbing in node core would be to explore doing it in C, by using the same actual code that expands patterns in bash or zsh. I'm not sure if their licenses would be compatible, of course, and bash globs are pretty slow on large folder trees, compared to node-glob or especially fastglob. But you can't get more consistent than "using the same code".

    But anyway, yeah, if it was up to me, I'd say just let glob live in userland. It's fine there.

  13. isaacs commented on Apr 7, 2023

    @isaacs
    Contributor

    @kaizhu256 If you really want your tool to support globs faithfully, and remain "zero-dep", there's an easy solution.

    npm install glob@latest --no-save
    mv node_modules vendor
    echo 'module.exports = require("../vendor/glob")' > lib/glob.js
    

    😜

  14. benjamingr commented on Apr 10, 2023

    @benjamingr
    Member

    But anyway, yeah, if it was up to me, I'd say just let glob live in userland. It's fine there.

    The issue mostly is that it's increasingly a common request needed by other Node.js features (like the test runner) that are seeing bigger and bigger adoption.

  15. isaacs commented on Apr 10, 2023

    @isaacs
    Contributor

    @benjamingr Then the thing to do, imo, is to bundle node-glob (if you want as correct/complete results as possible) or fast-glob (if you want as fast performance as possible), and call it a day. The difference is minor, node-glob is still very fast, and fast-glob is still very correct. Both are a much better fit for node than libglob can ever be.

  16. benjamingr commented on Apr 11, 2023

    @benjamingr
    Member

    Personally I agree and it's also likely better in terms of ease of understanding the code for most contributors, security and updates.

    If Node wants to expose it as a built in API no one is stopping us from upstreaming changes making things like "throw Node's own errors" or "use primordials if node-glob is built with this or that flag" to node-glob or whatever we choose (in the error case Node can just wrap the errors like it does with other deps)

  17. github-actions commented on Oct 9, 2023

    @github-actions
    Contributor

    There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

    For more information on how the project manages feature requests, please consult the feature request management document.

  18. added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Oct 9, 2023
  19. removed
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Nov 2, 2023
  20. boneskull commented on Mar 20, 2024

    @boneskull
    Member

    Please allow me to necro this issue because of #51912

    My current workaround:

    glob -c "tsx --test" "./src/test/*.spec.ts"
  21. moved this from Awaiting Triage to Done in Node.js feature requestson Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions