8000 Turn off Electron asar archive support. by tgds · Pull Request #628 · shelljs/shelljs · GitHub
[go: up one dir, main page]

Skip to content

Turn off Electron asar archive support. #628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Conversation

tgds
Copy link
@tgds tgds commented Dec 19, 2016

ShellJS fails to remove asar archives when run in Electron due to
Electron fs patches that treat asar archives as virtual directories.
See issue #618 .
To overcome this, we set process.noAsar to true.

ShellJS fails to remove asar archives when run in Electron due to
Electron fs patches that treat asar archives as virtual directories.
See issue shelljs#618.
To overcome this, we set process.noAsar to true.
@nfischer
Copy link
Member

@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.

@tgds
Copy link
Author
tgds commented Dec 19, 2016

@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.

@nfischer
Copy link
Member

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.

@nfischer
Copy link
Member

@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.

@nfischer
Copy link
Member
nfischer commented Jan 9, 2017

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

@nfischer nfischer closed this Jan 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0