Commit Graph

7 Commits

Author SHA1 Message Date
Anton Nikolaev
b3274a8450 Plugin folders re-structuring
Summary:
Here I'm changing plugin repository structure to allow re-using of shared packages between both public and fb-internal plugins, and to ensure that public plugins has their own yarn.lock as this will be required to implement reproducible jobs checking plugin compatibility with released flipper versions.

Please note that there are a lot of moved files in this diff, make sure to click "Expand all" to see all that actually changed (there are not much of them actually).

New proposed structure for plugin packages:
```
- root
- node_modules - modules included into Flipper: flipper, flipper-plugin, react, antd, emotion
-- plugins
 --- node_modules - modules used by both public and fb-internal plugins (shared libs will be linked here, see D27034936)
 --- public
---- node_modules - modules used by public plugins
---- pluginA
----- node_modules - modules used by plugin A exclusively
---- pluginB
----- node_modules - modules used by plugin B exclusively
 --- fb
---- node_modules - modules used by fb-internal plugins
---- pluginC
----- node_modules - modules used by plugin C exclusively
---- pluginD
----- node_modules - modules used by plugin D exclusively
```
I've moved all public plugins under dir "plugins/public" and excluded them from root yarn workspaces. Instead, they will have their own yarn workspaces config and yarn.lock and they will use flipper modules as peer dependencies.

Reviewed By: mweststrate

Differential Revision: D27034108

fbshipit-source-id: c2310e3c5bfe7526033f51b46c0ae40199fd7586
2021-04-09 05:22:00 -07:00
Anton Nikolaev
02d695cb28 Keep multiple installed versions of each plugin
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
2020-12-15 09:31:54 -08:00
Anton Nikolaev
5b26f36672 Plugin Marketplace API
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
2020-12-15 09:31:54 -08:00
Anton Nikolaev
d4debc4185 Use dotenv for dev mode customisation
Summary: Allow using of .env file to pass env vars to be used in dev mode. Currently this allow to configure defaults for enabling fast refresh, automatic opening of dev tools and plugins to load.

Reviewed By: passy

Differential Revision: D24398938

fbshipit-source-id: 30a5d86b7906a7723a404cf84a1b8d50ae497dbc
2020-10-22 11:35:53 -07:00
Anton Nikolaev
f03d5d94ed Remove plugin compilation and loading from startup hot path
Summary:
- Removed compilation on startup which is not required anymore after switching to plugin spec v2.
- Removed from Node process ("static" package) all the dependencies which are not required anymore:  e.g. metro, babel etc.
- Plugin loading code from node process moved to browser process and made asyncronous.

Some expected benefits after these changes:
1) Reduced size of Flipper bundle (~4.5MB reduction for lzma package in my tests) as well as startup time. It's hard to say the exact startup time difference as it is very machine-dependent, and on my machine it was already fast ~1500ms (vs 5500ms for p95) and decreased by just 100ms. But I think we should definitely see some improvements on "launch time" analytics graph for p95/p99.
2) Plugin loading is async now and happens when UI is already shown, so perceptive startup time should be also better now.
3) All plugin loading code is now consolidated in "app/dispatcher/plugins.tsx" instead of being splitted between Node and Browser processes as before. So it will be easier to debug plugin loading.
4) Now it is possible to apply updates of plugins by simple refresh of browser window instead of full Electron process restart as before.
5) 60% less code in Node process. This is good because it is harder to debug changes in Node process than in Browser process, especially taking in account differences between dev/release builds. Because of this Node process often ended up broken after changes. Hopefully now it will be more stable.

Changelog: changed the way of plugin loading, and removed obsolete dependencies, which should reduce bundle size and startup time.

Reviewed By: passy

Differential Revision: D23682756

fbshipit-source-id: 8445c877234b41c73853cebe585e2fdb1638b2c9
2020-09-16 06:32:58 -07:00
Anton Nikolaev
eeded4e32f Install plugins to pending directory first to enable installing new versions of existing plugins
Summary:
Install plugins to pending directory first to enable installing new versions of existing plugins. On startup Flipper moves all the plugins from pending directory into installed plugins directory.

Auto-update, after downloading a plugin package, will also extract it to "pending", so after restart update will automatically be applied.

Reviewed By: mweststrate

Differential Revision: D21929713

fbshipit-source-id: 141b106415e941156ae598cf810ab3bed8c76ced
2020-06-09 04:58:36 -07:00
Anton Nikolaev
db3f04a2d7 Use the single type representing plugins
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
2020-06-08 08:57:07 -07:00