search

onivim / oni

Oni: Modern Modal Editing - powered by Neovim
https://www.onivim.io
MIT License
11.34k stars 299 forks source link

Enable Asar packaging for installation #350

Open bryphe opened 7 years ago

bryphe commented 7 years ago

For v0.2, the asar option was set to false - meaning the app is not bundled into an asar archive. The electron-builder docs recommend keeping this as true, but excluding certain files. This can also help with the app launch speed. On all platforms, we get this warning due to disabling asar packing:

Packaging using asar archive is disabled — it is strongly not recommended.

To re-enable it, the files in the bin folder must be excluded.

bryphe commented 7 years ago

The fix for this issue should:

bryphe commented 7 years ago

Bringing this back, as the asar package unfortunately regressed package size. The files / folders specified in asarUnpack are actually still stored in the asar package - almost doubling the size!

Will need to follow up and see if there is a configuration change to avoid this, otherwise, we may need a custom packaging strategy or see if there is a possibility of pushing a fix to electron-builder.

When this is addressed, will need to update the app icon in the setup scripts (#613)

CrossR commented 6 years ago

I've had a look at this now that my PR was merged.

Is my understanding correct that we'd need to unpack the entire extensions folder, certain node modules (ripgrep, neovim, LSP like CSS/Reason/etc, typescript, reason, oni-api), the vim and images folder, and then update all places where we try to do node_modules/X/... to app.asar.unpacked/node_modules/X/... and ensuring that whatever folder it was trying to access is unpacked?

I've got the very most basic version of it running again, with Oni launching and linked to nvim (though it fails with colourschemes since I don't have extensions unpacked).

EDIT: Had a bit more of a look into it, and it looks like they shouldn't be specified using asarUnpack, but rather as extra resources, at least according to https://github.com/electron-userland/electron-builder/issues/2290. From a quick test, I saw the same behaviour as the previous PR, where things were in both the asar file, and the unpack folder, so we may need to do it this way instead.

bryphe commented 6 years ago

I've had a look at this now that my PR was merged.

Sweet! Thanks @CrossR !

Is my understanding correct that we'd need to unpack the entire extensions folder, certain node modules (ripgrep, neovim, LSP like CSS/Reason/etc, typescript, reason, oni-api), the vim and images folder, and then update all places where we try to do node_modules/X/... to app.asar.unpacked/node_modules/X/... and ensuring that whatever folder it was trying to access is unpacked?

I'm not sure the 'unpack' option will really work the way we want it to. I think what would be better for us is to pack our asar manually, and then make sure it gets to the right place. I was thinking we'd maintain a 'blacklist' of things that shouldn't get packed into the asar (the neovim binaries, ripgrep, vim folder, images, etc) - and everything else would go to there.

If we set it up correctly, we shouldn't need to remap any of our paths to app.asar.unpacked - it should be transparent to the require(...) system. And for anything that we need to open up the file directly - we should have that be outside the asar.

Sounds like the extraResources might be a way to accomplish this too, without us needing to manually manage the asar packing! I was under the impression we'd need to manually manage the packing process, but if we can handle it though the extraResources parameter - that would be great.