Summary:
See previous diff, if the plugin `id` on the class definition mismatches with the `package.json`, the navigation in Sandy will use the wrong id (from the meta data) causing the plugin not to open.
Since the `id` exposed on the class is the one that is used to setup the connect on the client, updated the ids in the `package.json` which have afaik no further meaning.
Pinging nikoant to verify that assumption. I can imagine this might impact historical data / plugin distribution?
Reviewed By: passy, nikoant
Differential Revision: D25302542
fbshipit-source-id: 43fe1667604eb7a28f6f9b7d260bc2a1e6e82dd3
Summary:
Context: https://fb.workplace.com/groups/flippersupport/permalink/1005193786627946/
I believe we can land this without knowing that it works, because iOS support is still disabled by default for non mac devices - you have to enable it in settings to switch it on.
Reviewed By: passy
Differential Revision: D24893757
fbshipit-source-id: c9db515a7807c94a0d5e509017dd4e1796d24f6d
Summary: This prefixes APIs of `flipper-plugin`, that are used by Flipper, but should not be used by plugins directly, with `_`. Also added tests to make sure we are always intentional when extending the exposed APIs
Reviewed By: passy
Differential Revision: D24991700
fbshipit-source-id: ed3700efa188fca7f5a14d5c68250598cf011e42
Summary:
Before this change, launching a simulator would ony show the simulator if the simulator process itself was already running. This makes sure that opening a simulator also works from a closed state
Changelog: Automatically start an iOS simulator to launch a device when none is running yet
Reviewed By: nikoant
Differential Revision: D24919363
fbshipit-source-id: 45039330710cf81aa73222967d667964bb01f42a
Summary: Currently we load all the plugins even if they are not required in dev mode, e.g. when you are developing a specific plugin. This diff adds an env var and command-line option to specify exact list of plugins to load. This makes dev mode startup faster and consume less memory.
Reviewed By: passy
Differential Revision: D24394146
fbshipit-source-id: 42a78c1ffb2632e657c2411e34e9c80fff18df3a
Summary: Tests to verify the more complex selection logic resulting from the Metro device exception. Also verifies the logic that computes the available plugins
Reviewed By: nikoant
Differential Revision: D24445555
fbshipit-source-id: 70110c4470e6aa1356e814aa40744b65c21cad89
Summary: When trying to refactor some components, did once again run into circular imports that cause the flipper startup sequence to fail. Added linting rules to make sure this is much less likely to happen in the future, and fixed all resulting errors
Reviewed By: nikoant
Differential Revision: D24390583
fbshipit-source-id: 9b20cf6a4d3555dc68f0069c2950dd7162b17e67
Summary:
Changelog: Flipper can now launch iOS simulators by using `File > Launch Emulator...`
In the Sandy designs the device selector dropdown no longer shows the option to launch an emulator. So added a button to app inspect and the main menu instead.
I found it always a bit funny that we can launch android emulators, but not iOS emulators. Turns out that launching them is actually not very complex, so added capabilities to launch ios emulators
Reviewed By: jknoxville
Differential Revision: D24021737
fbshipit-source-id: c106cc2246921e008f9c808ebb811d8e333aa93b
Summary: Implemented a way for re-loading single plugin on auto-update. This make it possible to apply update without full Flipper restart.
Reviewed By: mweststrate
Differential Revision: D23729972
fbshipit-source-id: ed30f7cde5a0537945db0b5bb6969ae8fde42cb6
Summary:
Probably more than just KitKat, but we got a specific report in
https://fburl.com/f88cvz4c for 4.4. ABI lists are not included
in the probs and unfortunately TS doesn't resolve this to a
`string | undefined` as it should.
{F336605489}
Reviewed By: jknoxville
Differential Revision: D23815568
fbshipit-source-id: b6af928f85549d0c973feb0d83a324252ce0f654
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
Summary:
Do not list plugins packaged with format v1 in Plugin Manager.
Changelog: removed support for plugins packaged using legacy format (v1), so they won't appear in Plugin Manager anymore.
Reviewed By: passy
Differential Revision: D23681402
fbshipit-source-id: 1c9496ba6b739069d67228a0f4250f2f01aabd4d
Summary:
Sorry for so long diff, but actually there are no functional changes, just refactoring to make further changes of Plugin Manager easier to understand.
I've de-coupled the code related to plugin management from UI code and moved it from PluginInstaller UI component (which will be replaced soon by new UI) to "flipper-plugin-lib". So pretty much everything related to plugin discovery and installation now consolidated in this package.
Additionally, this refactoring enables re-using of plugin management code in "flipper-pkg", e.g. to create CLI command for plugin installation from NPM, e.g.: `flipper-pkg install flipper-plugin-reactotron`.
Reviewed By: passy
Differential Revision: D23679346
fbshipit-source-id: 82e7b9de9afa08c508c1b228c2038b4ba423571c
Summary: This diff fires a notification with a remediation suggestion when the client takes a long time to connect back, for both WW and FS_ACCESS case
Reviewed By: mweststrate
Differential Revision: D23321067
fbshipit-source-id: 17ab93974e9571a0ba78af05c624eeb0522637c6
Summary:
Note: this is to be stacked upon https://github.com/facebook/flipper/pull/1479
Note: this PR will probably not succeed against FB internal flipper, as I'm pretty sure there are more call sites that need to be updated. So consider this WIP
Currently connection errors are managed in the connection reducers, and are displayed through their own means, the error bar. Showing console.errors is also hooked up to this mechanism in FB internal flipper, but not at all in the OSS version, which means that some connection errors are never shown to the user.
Besides that there is a notification system that is used by for example the crash reporter and plugin updater.
Having effectively (at least) two notifications mechanisms is confusing and error prone. This PR unifies both approaches, and rather than having the connection reducer manage it's own errors, it leverages the more generic notifications reducer. Since, in the previous PR, console errors and warnings have become user facing (even in OSS and production builds, which wasn't the case before), there is no need anymore for a separate error bar.
I left the notifications mechanism itself as-is, but as discussed in the Sandy project the notification screen will probably be overhauled, and the system wide notifications will become in-app notifications.
## Changelog
Pull Request resolved: https://github.com/facebook/flipper/pull/1483
Test Plan: Only updated the unit tests at this point. Manual tests still need to be done.
Reviewed By: passy
Differential Revision: D23220896
Pulled By: mweststrate
fbshipit-source-id: 8ea37cf69ce9605dc232ca90afe9e2f70da26652
Summary:
Converted the DeviceLogs plugin to sandy.
Kept logic and UI the same (so same batching, localstorage mechanisms etc). But used sandy api's for log subscribing, state, and separating the logical part of the component from the UI.
Note that some mechanisms work slightly different, like deeplinking and scrollToBottom handling, to reflect the fact that plugins are now long lived
Reviewed By: jknoxville
Differential Revision: D22845466
fbshipit-source-id: 7c98b2ddd9121dc730768ee1bece7e71bb5bec16
Summary:
Running `instruments -s devices` causes the `pkd` process in catalina to spike to ~100% for a few seconds.
Flipper runs this command every 3 seconds to poll for devices.
This switches it to use `idb list-targets` instead which is much more performant.
Currently switched off in the open-source version while we make sure it's working well. If you set the GK value 'flipper_use_idb_to_list_devices' to true, then you'll get the new behaviour.
Reviewed By: passy
Differential Revision: D23102067
fbshipit-source-id: 9e17155d938a4fe326e082511f747444e4b533a2
Summary:
[interesting] since it shows how Flipper APIs are exposed through sandy. However, the next diff is a much simpler example of that
This diff adds support for adding menu entries for sandy plugin (renamed keyboard actions to menus, as it always creates a menu entry, but not necessarily a keyboard shortcut)
```
client.addMenuEntry(
// custom entry
{
label: 'Reset Selection',
topLevelMenu: 'Edit',
handler: () => {
selectedID.set(null);
},
},
// based on built-in action (sets standard label, shortcut)
{
action: 'createPaste',
handler: () => {
console.log('creating paste');
},
},
);
```
Most of this diff is introducing the concept of FlipperUtils, a set of static Flipper methods (not related to a device or client) that can be used from Sandy. This will for example be used to implement things as `createPaste` as well
Reviewed By: nikoant
Differential Revision: D22766990
fbshipit-source-id: ce90af3b700e6c3d9a779a3bab4673ba356f3933
Summary:
The device type enum was mixing two different concepts (emulator vs physical) and (archived vs not), and we already have a separate `isArchived` field. So cleaned this up to not leak it into sandy.
If anybody can think of any unforeseen consequences of this, lemme know :)
Reviewed By: jknoxville
Differential Revision: D22763506
fbshipit-source-id: bd2f7dbd1d2d2e6942ba7c6ddd8dc91ee34d591d
Summary: Introducing a base abstract class (blegh) to share some life cycle management between Device- and normal plugins. Cleaned up the test utils a bit as well + some old TODO's that now have been taken care of
Reviewed By: nikoant
Differential Revision: D22727089
fbshipit-source-id: 507816f1bfdbc6e7e71d4bd365b881b6710ca917
Summary: Add unit tests to verify that the unit test utilities for for Sandy device plugins work as expected. Fixed a bug revealed by that and cleaned up some TODO's
Reviewed By: jknoxville, passy, nikoant
Differential Revision: D22693928
fbshipit-source-id: 93162db19d826d0cd7f642cef1447fd756261ac8
Summary:
This stack introduces Sandy device plugins, they are quite similar to normal plugins, but, a devicePlugin module is organized as
```
export function supportsDevice(device): boolean
export function devicePlugin(devicePluginClient)
export function Component
```
Device plugins get access to the device meta data and can subscribe to the `onLogEntry` callback and `onDestroy` lifecycle.
They will be able to store state just as normal plugins, but can't send or receive methods, so devicePluginClient is a bit limited.
This diff only sets up most of the new data structures, and makes sure everything still compiles and no existing tests fail.
To prevent this diff from becoming to big, actually loading, rendering and testing device plugins will be done in next diffs
Please take a critical look at the api proposed and the (especially) the public names used :)
Reviewed By: passy, nikoant
Differential Revision: D22691351
fbshipit-source-id: bdbbd7f86d14b646fc9a693ad19f33583a76f26d
Summary:
Simple implementation of restart button on auto-update notifications. Should make the flow a bit more convenient.
Changelog: Added button "Restart Flipper" to plugin auto-update notifications.
Reviewed By: passy
Differential Revision: D22528729
fbshipit-source-id: 6da6b858baed1e0f3cae57f1a614907b61899d10
Summary: Fixed error on building standalone packages for "unity" apps. The error was because "immer" imports were not transformed to use "immer" from Flipper bundle.
Reviewed By: passy
Differential Revision: D22357571
fbshipit-source-id: 590321f36208c9ed02d56d2c0c085c7cd1878018
Summary: Really nothing interesting to see here , just moved pluginStats out of messageQueue, as it started there and kept growing
Reviewed By: nikoant
Differential Revision: D22257318
fbshipit-source-id: 26be7efb4629fcef1b14de96a2b60f17f7d76785
Summary:
This sets up the initial infra that is to be used by plugin devs to test plugins.
There is not much yet to see, as there is no state or message sending yet. But at least the life cycle of plugins can be test, things are strongly typed and everything is in the place where it should be :)
N.b. the import difference with these utils and the createFlipperMock utilities in Flipper are
1. this testing infra is entirely inside flipper-plugin package, so that plugin devs don't need flipper as a dependency
2. this testing infra doesn't provide abstractions for plugin / device / client switching; it tests plugins purely in isolation of the rest of the world (except for firing `onConnect` / `onDisconnect` which is normally the effect of switching plugins)
Reviewed By: nikoant
Differential Revision: D22255262
fbshipit-source-id: b94ccbab720d2b49428a646aed3c55af71a5bc80
Summary: Replaced `instanceof` checks with `isSandyPlugin` utility. That is cleaner to read and makes it easier to find places where we make exceptions for Sandy plugins
Reviewed By: jknoxville
Differential Revision: D22206707
fbshipit-source-id: b44a1b585424f3b9bf0d7ce200c34107f03ed55e
Summary: Unit tests tend to randomly bail out once FBLogger is (indirectly) required by some module under test. This makes sure FBLogger is stubbed by default. We might want to do the same for `User` in the future.
Reviewed By: jknoxville
Differential Revision: D22186274
fbshipit-source-id: 2ede364c4b691d69826781355592226b075d8367
Summary: Make sure Sandy plugins are loaded properly from disk
Reviewed By: jknoxville
Differential Revision: D22186275
fbshipit-source-id: fd2f560a7bed959b18e05db2a087909ad876ab9d
Summary:
So far there were 2 types of plugins: `FlipperPlugin` and `FlipperDevicePlugin`. This introduces a third kind: `SandyPluginDefinition`.
Unlike with the old plugins, the export of the module is not directly exposed as the plugin definition. Rather, we use class `SandyPluginDefinition` (instance) that holds a loaded definition and its meta data separately (`PluginDetails`). This means that we don't have to mix in and mutate loaded definitions, and that for unit tests we can avoid needing to provide a bunch of meta data. This also prevents a bunch of meta data existing on two places: on the loaded classes as static fields, and in the meta data field of the loaded class as well. Finally, we can now freely extends the `PluginDetails` interface in flipper, without needing to store it on the loaded classes and we are sure that no naming conflicts are caused by this in the future.
For compatibility with the existing code base, common fields are delegated from the `SandyPluginDefinition` class to the meta data.
Also cleaned up types around plugins a little bit and removed some unnecessary casts.
For all features that reason about plugins in general (such as exports), sandy plugins are ignored for now.
`SandyPluginInstance` is worked out in further diffs
The `instanceof` calls are replaced by a utility function in later diffs.
{F241363645}
Reviewed By: jknoxville
Differential Revision: D22091432
fbshipit-source-id: 3aa6b12fda5925268913779f3c3c9e84494438f8
Summary: Set up an initial library which can (should) be used by plugins in the future.
Reviewed By: jknoxville
Differential Revision: D22019554
fbshipit-source-id: 502b14b34b2c9c117cea377ab6ebbf150e6faee9
Summary: This diff adds abilist and sdk version information in the AndroidDevice.
Reviewed By: mweststrate
Differential Revision: D22210225
fbshipit-source-id: cda3dea9d89fdaa62a08aa000c93e39177c67bdd
Summary:
Show notification if user has installed plugins packaged in the old format. Example text of notification:
***
Plugin "Example" will stop working after version 0.48 of Flipper released, because it is packaged using the deprecated format.
Please try to install a newer version of this plugin packaged using "Install Plugins" tab on "Manage Plugins" form.
If the latest version of the plugin is still packaged in the old format, please contact the author and consider raising a pull request for upgrading the plugin. You can find contact details on the package page https://www.npmjs.com/package/flipper-plugin-example.
If you are the author of this plugin, please migrate your plugin to the new format, and publish new version of it. See https://fbflipper.com/docs/extending/js-setup#migration-to-the-new-plugin-specification on how to migrate the plugin. See https://fbflipper.com/docs/extending/js-setup#package-format for details on plugin package format.
***
Reviewed By: passy
Differential Revision: D22065688
fbshipit-source-id: da9b9d8f62e7cdb8c926a81e24bdfb4ec67f9dff
Summary: When Flipper is running in dev mode we should always use bundled version of plugin (e.g. loaded from sources) even if a newer version is installed. Otherwise it could happen that Flipper will load installed version and it will not be possible to test your changes of plugin sources.
Reviewed By: passy
Differential Revision: D22016564
fbshipit-source-id: fbf63d5248b60034dc61688e4faa9b54890b744e
Summary:
Adds a check for idb to flipper-doctor.
This depends on the flipper settings, to know where to look for idb, so I've made it so you can pass settings into the doctor when running it. When run from the command line, you don't get the settings. This is because settings loading currently depends on redux so I haven't extracted it into its own package.
Not that this will notify ALL open source iOS users with a doctor warning because they don't have idb installed. The error message says you can disable it in settings, which will silence this warning.
CHANGELOG: The open source version now works with physical iOS devices.
Reviewed By: passy
Differential Revision: D21883086
fbshipit-source-id: f28c43487e88a6c07ef3cc3da2764026726c9f18
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
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:
I noticed that Android device detection is _much_ faster than iOS, so I tried to optimize it a bit
1. Removed a test run on `instruments -s`. That command is really slow (easily 5 secs), and the check has become redundant since Doctor already does a similar check
2. When querying for devices, it tries to fetch emulated and physical devices in parallel, but only processes the results after both have finished. However, finding simulators is almost instant, while querying the physical devices takes ~5 seconds ore more. So in this diff we process the found devices till in parallel, rather than waiting until both have arrived
This diff reduces the time until the ios simulator + FB app is detected from 28 to 4 seconds on my machine.
Changelog: Improved the startup sequence for emulated iOS devices, so that devices and apps connect a lot faster after starting Flipper
Reviewed By: jknoxville
Differential Revision: D21907597
fbshipit-source-id: 73edf0b04c4ad8367e04557e33f4c0d9e9bcd710
Summary: Download updated plugins in background. This is implemented by periodical polling of Marketplace GraphQL API (interval 5 min by default). The feature is under GK flipper_plugin_auto_update, so for now it is enabled only for me.
Reviewed By: mweststrate
Differential Revision: D21863057
fbshipit-source-id: 51d8223ad4b2a928f7571ea480c10ba2efd9935d
Summary:
The last piece of the puzzle to get this working.
Now if a user has iOS development enabled in Flipper settings, and has XCode installed, we'll run the PortForwardingMacApp processes required to interact with iOS devices.
It's not great the way it starts the processes without any error checking, but since that's the way it currently works, I'm leaving it as it is for now.
Reviewed By: mweststrate
Differential Revision: D21881041
fbshipit-source-id: 1d1fdb7e0621cff88408bb707d768bb5c6bea0cc
Summary: Load either installed or bundled version of plugin depending on which is newer.
Reviewed By: mweststrate
Differential Revision: D21858965
fbshipit-source-id: aa46eafe0b5137134fadad827749672441f2c9e5
Summary:
I've outlined the tasks required to get iOS device support working for open source users [here](https://github.com/facebook/flipper/issues/262).
This is the first step. It publishes the same code we use internally to GitHub, but in a state where it is only "available" for non-public builds. This will not change any behavior, but means that together with the community, we can start adapting it to suit everyone, and then eventually flip "available" to true for everyone.
Reviewed By: passy
Differential Revision: D21740193
fbshipit-source-id: 586c79ad850f67da330c10a007605ff25a187544
