Summary:
Follow up of D32665064, this diff moves all plugin management logic from flipper-ui to flipper-server. Things like downloading, installing, querying new plugins.
Loading plugins is handled separately in the next diff.
Reviewed By: nikoant
Differential Revision: D32666537
fbshipit-source-id: 9786b82987f00180bb26200e38735b334dc4d5c3
Summary: Moved all types related to plugin descriptions from plugin-lib (which handles downloads and such) to flipper-common. The goal of that is to remove all plugin-lib usage from ui-core to server-core, so that the UI itself doesn't do any file operations anymore related to plugins. That will be done in next diffs, this just moves types but no code.
Reviewed By: nikoant, aigoncharov
Differential Revision: D32665064
fbshipit-source-id: 86d908e7264569b0229b09290a891171876c8e00
Summary:
- This Diff is part 1 of 2 of milestone 1 of my internship project flipper self sufficiency. The task can be found here - https://www.internalfb.com/tasks?q=958574791613645&t=91334896
- I have extended the plugin package meta data format to support a "supportedApps" field that consists of appID (facebook, instagram, messenger etc) along with OS and type that were previously defined in supportedDevices as well.
- The diff also adds unit tests for this new format to ensure addition of the supportedApps field does not break anything.
Reviewed By: nikoant
Differential Revision: D30133225
fbshipit-source-id: 6ef0d1cadd61c0d69640cf61793322acb4cd65f4
Summary: Allow splitting package.json to public one and fb-internal one located in "fb/package.json". When plugin is packaged, fields in package.json are overwritten by fields from "fb/package.json" if they exist. This give us a way to specify additional metadata which only make sense internally (e.g. oncall and internal links to docs and support).
Reviewed By: mweststrate
Differential Revision: D28542101
fbshipit-source-id: c0167461897a994e5731aaf0fe625de052eda864
Summary:
Sorry for long diff! I can try to split it if necessary, but many changes here are 1-1 replacements / renames.
**Preambule**
Currently we bundle default plugins into the Flipper main bundle. This helps us to reduce bundle size, because of plugin dependencies re-use. E.g. if multiple plugins use "lodash" when they are bundled together, only one copy of "lodash" added. When they are bundled separately, the same dependency might be added to each of them. However as we're not going to include most of plugins into Flipper distributive anymore and going to rely on Marketplace instead, this bundling doesn't provide significant size benefits anymore. In addition to that, bundling makes it impossible to differentiate whether thrown errors are originated from Flipper core or one of its plugins.
Why don't we remove plugin bundling at all? Because for "dev mode" it actually quite useful. It makes dev build start much faster and also enables using of Fast Refresh for plugin development (fast refresh won't work for plugins loaded from disk).
**Changes**
This diff introduces new option "no-bundled-plugins" for "yarn start" and "yarn build" commands. For now, by default, we will continue bundling default plugins into the Flipper main bundle, but if this option provided then we will build each default plugin separately and include their packages into the Flipper distributive as "pre-installed" to be able to load them from disk even without access to Marketplace.
For "yarn start", we're adding symlinks to plugin folders in "static/defaultPlugins" and then they are loaded by Flipper. For "yarn build" we are dereferencing these symlinks to include physical files of plugins into folder "defaultPlugins" of the produced distributive. Folder "defaultPlugins" is excluded from asar, because loading of plugins from asar archive might introduce some unexpected issues depending on their implementation.
Reviewed By: mweststrate
Differential Revision: D28431838
fbshipit-source-id: f7757e9f5ba9183ed918d70252de3ce0e823177d
Summary: Currently, when user installs a new plugin which was not installed before that, Flipper always takes the latest available version of it. This is not correct, because the latest version might be incompatible with the currently running version of Flipper. To avoid that, instead of always using just the latest version we will be using the most recent version which is compatible with the current Flipper version.
Reviewed By: passy
Differential Revision: D28306505
fbshipit-source-id: 4258a456d6a5d92cbf48af55c0efb17ecf560b57
Summary:
*Stack summary*: this stack adds ability to manage device plugins in the same way as client plugins: install, update, uninstall, enable (star) and disable (unstar) them.
*Diff summary*: changed the way how plugin compatibility with devices is checked from dynamic call to "supportsDevice" to static checks of "supportedDevices" metadata property which make it possible to check compatibility without even downloading plugin from Marketplace.
Changelog: plugin compatibility with devices is now checked according to metadata in property "supportedDevices" in package.json
Reviewed By: mweststrate
Differential Revision: D26315848
fbshipit-source-id: 6e4b052c4ea0507ee185fc17999b6211cdb11093
Summary: Plugin metadata format extended to include type of each plugin (client / device) and list of supported devices (android/ios/..., emulator/physical, etc). This will allow to detect plugins supported by device even if they are not installed and only available on Marketplace.
Reviewed By: mweststrate
Differential Revision: D26073531
fbshipit-source-id: e331f1be1af1046cd4220a286a1d52378c26cc53
Summary:
I've re-designed interfaces describing plugins as I found that mental overhead working with them became too expensive because of slightly flawed design. However this cascaded changes in many files so you can see how extensively these interfaces used in our codebase.
Before this change we had one interface PluginDetails which described three different entities: 1) plugins installed on the disk 2) plugins bundled into Flipper 3) plugins available on Marketplace. It's hard to use this "general" PluginDetails interface because of this as you always need to think about all three use cases everywhere.
After this change we have 3 separate interfaces: InstalledPluginDetails, BundledPluginDetails and DownloadablePluginDetails and things became much type-safer now.
Reviewed By: mweststrate
Differential Revision: D25530383
fbshipit-source-id: b93593916a980c04e36dc6ffa168797645a0ff9c
Summary:
This diff changes directory structure for installed plugins to allow installation of multiple versions simultaneously, e.g. to to allow downloading new plugin version while user is still using the previous one, and to have possibility of fast rollback to the previous installed if necessary. The new folder for installed plugins is located in `~/.flipper/installed-plugins` and has the following structure:
flipper-plugin-reactotron
1.0.0
...
package.json
1.0.1
...
package.json
flipper-plugin-network
0.67.1
...
package.json
0.67.2
...
package.json
The tricky part here is that we also need to migrate already installed plugins from the old folder `~/.flipper/thirdparty` to the new folder and maintain the new structure for them.
Another tricky part is that we need to periodically cleanup old versions. For now we will just keep 2 versions of each plugin. Cleanup is performed in background right after Flipper startup.
Reviewed By: mweststrate
Differential Revision: D25393474
fbshipit-source-id: 26617ac26114148f797cc3d6765a42242edc205e
Summary: Extracted plugin marketplace API to a separate file and updated it to load full plugin manifests.
Reviewed By: passy
Differential Revision: D25181759
fbshipit-source-id: a63f9ce16249ccc170df148cef5c209fdc6d4d6d
Summary:
To know whether plugins should be mounted with the old setup or new setup (with a Provided / context based api), we need to be able to recognize whether a plugin is written with the old or new setup.
We do this by checking if the flipper-plugin dependency is declared as peer dependency. This we can to check for SDK compatibility as well.
Reviewed By: jknoxville
Differential Revision: D22043085
fbshipit-source-id: 21afabb6e58d86253a464470f4690c51cced87ab
Summary: Use interface PluginDetails everywhere where plugins are handled and removed PluginDefinition type which was effectively a subset of PluginDetails
Reviewed By: mweststrate
Differential Revision: D21927456
fbshipit-source-id: 434ebeef955b922cc11757e78fbba8dec05f1060
Summary: Added "description" field to PluginDetails interface and read it from package.json
Reviewed By: passy
Differential Revision: D21927391
fbshipit-source-id: 0513637d3afa3d8be8e2bc8ee87cc1d77c5e2250
