rimraf: Invalid path error in windows

glob pattern was a great feature of rimraf. I miss it a lot. Wonder if there’s a chance to get it back

Yeah, people seem to really miss it. It’s a sad fact of open source that you mostly only hear from people when something bothers them, so over the years, I’d gotten the (perhaps mistaken!) impression that the automatic globbing was a big problem, because I only heard about it when it caused issues.

But maybe now that it’s removed, and I’m hearing about the issues that it causes to remove it. Life is funny that way.

So yes, given the responses here, there is a chance to get it back, but I need to finish the rewrite of glob v9 first. It’s mostly there, just have to work out a pathological performance issue. (Oops, I said “just”. It might “just” require completely rethinking the v9 approach, but I think there’s probably a clever way through it.) Once that’s done, it’ll have a much less dated API, more resilience in the face of various filesystem issues, and have speed on par with the other implementations that have been developed in the many years since node-glob was first written.

In the meantime, you can use glob itself directly quite easily:

// rimraf-glob.cjs
const glob = require('glob')
const rimraf = require('rimraf') 
const rimrafWithGlob = async (pattern, rimrafOptions = {}, globOptions = {}) =>
  new Promise((res, rej) => {
    glob(pattern, globOptions, (err, results) => err ? rej(err) : res(rimraf(results, rimrafOptions)))
  })

if (require.main === module) {
  Promise.all(process.argv.slice(2).map(async (p) => rimrafWithGlob(p))
}

Landed on 4.2.0

Yeah, passing glob:{...options} also works

Keep in mind, you will have to add --glob to the command line or {glob:true} in the options if upgrading from v3.

Duly noted, we anyways in most cases passed glob options in form of { glob: { ... } } to rimraf, meaning glob support is enabled “by default”. However I will check the cases where we are not passing any glob options and pass true instead, to make sure globbing support is enabled. Thanks again for the quick turnaround in re-introducing that feature. Highly appreciated.

@kai-dorschner-twinsity Just npm i rimraf@3 to get version 3. It’s a SemVer major version, the only way you would have gotten it unexpectedly would have been a fresh install in a new project, or an unsafe dependency range like "rimraf": "*" in package.json.

In the meantime, if you want to use it with globs, just npm install glob, and write a script like I showed in the comment above. https://github.com/isaacs/rimraf/issues/251#issuecomment-1396315827

Save that as rimraf-glob.cjs and instead of having your script be "whatever": "rimraf some/*/glob/+(pa|ths)" or rimraf ./**/node_modules on the shell, make it "whatever": "node rimraf-glob.cjs some/*/glob/+(pa|ths)" or node rimraf-glob.cjs ./**/node_modules on the shell.

Or, if you’re using Bash version 4 or greater, you can add shopt -s globstar ; shopt -s extglob to your ~/.bashrc file, and then rimraf ./**/node_modules will work on the shell, or even rm -rf ./**/node_modules, because the shell will expand the globs for you before rimraf or rm even sees them. For example:

$ node -e 'console.log(process.argv.slice(1))' test/+(bin|readdir)*
[ 'test/bin.js', 'test/readdir-or-error.js' ]

Of course, that’ll probably never work on Powershell or cmd.exe, but installing glob and using your own script would work fine on any platform.

Unfortunately also our code is hard breaking since glob support was removed in version 4, especially because we also used it to spare some directories from deletion, using the { glob: { ignore: ..., nodir: true } option. Is there a alternative? Like a helper or pattern so we can continue using glob?