Closed hugomano closed 5 years ago
Yeah, well done 👏
Some general feedbacks:
IUpdate
instead of UpdateDescriptor
. It's a good convention in the TS world.Promise<IInstalledExtensions>
instead of Promise<Map<string, Map<string, InstallDescriptor>>>
WHAT IS THIS PR
This PR builds a new module to download, install and manage Chrome Extensions (further named Cx). It is NOT taking care of activation or settings, it is only the fetching and tracking installations of Cx and their update over the wire.
HOW DOES IT WORK
The
CxFetcher
module is meant as the main exposed service and serves the higher functionalities, such as "install/update Cx", "detect installed Cx", "auto update", keep track of their status. It is a conductor, built upon 3 submodules, each handling a different part of the process.DownloadProvider: module handling the download of the Cx archive (
.crx
) in the Google store. It needs an extension ID and returns anIDownload
, holding information for the following installation.StorageProvider: module handling the physical installation and storage of the Cx files. It extracts an archive (referenced in the
IDownload
), read and parses the manifest (transform it into a JSON object), move the files to the storing location (in Electron user data), and provides back anIInstall
holding the necessary information for theCxFetcher
(orInterpreterProvider
) to register the Cx.InterpreterProvider: module that interprets a manifest JSON object to extract version number, update URL and other necessary information for the
CxFetcher
. Can read and parse version numbers to compare them, or other utilities related to specific manifest and Cx format.The 3 submodules are meant to be built in isolation and can be modified, overridden, or replaced by different implementations. As long as the data that they exchange are coherent, none of them needs to know how the other is working. This allows, for example, to modify the storage without changing how the
CxFetcher
works.The
CxFetcher
is built with a dependency injection pattern, avoiding strong coupling. The types define the contract between all modules.TEST INSTRUCTIONS
There are two things to try :
Playground
npm start
)Everything should flow smoothly, gmelius is fetched, installed and loaded. Et voilà ! You can toy here to fetch and add more extensions, at launch, or try other functionalities.
Unit tests
⚠️Tests are covering the core of the module, but some edge cases and lesser functionalities are WIP (described but not implemented yet). Shoutout to @hugomano for mocking
electron-fetch
andelectron app
in the test environment.npm test
.You should see a test app starting (blank window), and in related dev tools -> console tab, you will find the results of the tests.
🗒 Note that the test folder has an "assets" folder that holds a Crx archive and other artifacts used to test some submodules and functionalities.