Inline Rimraf #300
Inline Rimraf #300
Conversation
This will come first. |
|
OK, thanks. |
| } | ||
|
|
||
| // this one won't happen if graceful-fs is used. | ||
| if (er.code === 'EMFILE' && timeout < options.emfileWait) { |
There was a problem hiding this comment.
@jprichardson This is a custom handler for EMFILE errors, only needed if you are using a custom fs. This brings up a question; when we add custom fs module support, will we add checks for EMFILE errors (where possible) across fs-extra?
There was a problem hiding this comment.
will we add checks for EMFILE errors (where possible) across fs-extra?
I don't think so, at least not in the short-term.
There was a problem hiding this comment.
OK, then I guess I'll remove these checks here.
There was a problem hiding this comment.
OK, then I guess I'll remove these checks here.
I don't think it hurts to keep them. Whatever is the shortest path and saves you time!
There was a problem hiding this comment.
@jprichardson I thought I would remove them in interests of a consistent api. If they are left here, remove will handle EMFILE errors while the rest of the api won't (when using custom fs modules).
We aren't using rimraf's glob support, and glob is a rather large dependency. Changes: - Remove glob support from rimraf - Remove move()'s dependency on rimraf; use fs-extra.remove instead - Make rimraf a devDependency; it is used in the tests
|
@jprichardson Done & rebased. Anything else? What else needs done for v1.0.0? |
|
Thanks!
I think removing |
We aren't using rimraf's glob support, and glob is a rather large dependency.
Changes:
Original comment:
@jprichardson This is my WIP of inlining rimraf. This needs rebased, do not merge.
rimraf has functionality built in to handle alternate
fsmodules. Currently, there is no way for the end-user to leverage that functionality. I could simplify the code by removing that, however, I don't want to have to add it back. Will we be adding customfsmodule support or glob support tofs-extrafirst?