babel/generator-babel-boilerplate

use rimraf

Closed this issue · 6 comments

Deleted user commented

Try to use rimraf instead of clear ( deprecated) and del as in your package.json. This too can cause problems with nodejs@newest. Depends on the use case of this boilerplate.

This is an easy switch as shown here: https://github.com/Kflash/ES2015/blob/master/gulpfile.js#L73-L76

jamesplease commented

Thanks for the issue @KFlash!

clear ( deprecated)

What is clear?

This too can cause problems with nodejs@newest.

Can you be more explicit here? What problems?

Deleted user commented

@jmeas You are not using clear. Clearing the console. And also gulp-clean as serve the same purpose as del state very clear about rimraf: closehttps://www.npmjs.com/package/gulp-clean

For your other question. I'm not a living lexicon, Google will help. But there have been issues where the folder got locked by the fs so you can't touch it anymore. As one thing. There are others too

jamesplease commented

@KFlash, Gulp's documentation uses del in their example...so I think it's probably fine. Also, del uses rimraf under the hood, so I'd be really surprised if folders being locked was caused by del and not rimraf.

Deleted user commented

@jmeas As I wrote earlier. I'm out of this, and your repo.

As and end, I copy this console messages I get with your del and your setup:

[02:30:39] Error: EBUSY, unlink ...
at Error (native)

This error I got with current clean task

And I don't even think you know that this error frequently popups only on windows based computers if you are using Power Shell in Windows 10 TP as one example, You will not get this error if you are running it inside the Github shell.

Deleted user commented

@jmeas but Ofc I can be wrong when it comes to your use case. But with my over 30 years experience in this game I'm used to see wider. What fit for one person don't need to fit for another one. Errors you experience another one probably would not see or find. Depends on the use case. Bye!

jamesplease commented

@fklash, it looks like you switched back to del in your own modification of this boilerplate, so I'm going to assume this issue was resolved on your end. Gonna close for now. If any other Windows folks have issues, just leave a comment here and we can revisit the problem!