@tgds Thanks for the patch. I agree that electron support is something we need to work on, and I'd like to move toward that in future releases.

From the looks of it, this seems like something end users might prefer to do on their own. I have reservations about modifying globals, especially since ShellJS is often used with other packages. This has led in the past to some hard-to-find bugs.

Although we're resetting noAsar's value here, it's still not a total perfect reset, since things subtly change (fails 'key' in obj check):

> // in regular node
> 'noAsar' in process
false
> var noAsar = process.noAsar
undefined
> process.noAsar = noAsar
undefined
> 'noAsar' in process // this value has changed, which end users might not expect
true

Even if we perfectly restore the state, there's always a chance that rm() will change in the future and might unexpectedly skip the cleanup steps, which would be hard to diagnose.

In the interest of kicking off support for electron, what if we instead document this in a new ShellJS wiki page, specifically for electron issues? That way ShellJS users know what to do and won't be surprised if this change breaks some other behavior.

@nfischer Yeah, certainly doesn't feel like the cleanest solution. Very much appreciate your feedback, I still need to develop the sense of knowing what one can safely afford to do.
How about requiring original-fs instead of fs when it's available? I know this would again be a little messy since we would be using slightly different fs library at one place.

Is there a reason why requiring users to use process.noAsar = true; before calling shell.rm() is not feasible?

Using original-fs might be the right approach. This approach is certainly safer, but we would probably need to add electron as an environment we test against in CI, which probably won't happen for a while.

Are there any scenarios where rm is useful if noAsar isn't modified? Also, does this asar stuff make cat, cp, etc. more useful or less useful? I wouldn't want to do anything until we're sure we aren't breaking a valid use case.

@tgds I started this wiki page for documenting electron support. I think I can hack something out pretty quickly to expose a workaround for exec(). If you find any other issues with electron support, let me know and I'll see if we can find reasonable workarounds.

Depending on how difficult electron support is, this may be slated for our v0.8 or v0.9 release, but we should probably stick with reasonable workarounds at least until then.

Closing, for the reasons noted in #618. We can reopen if documentation isn't sufficient.