Summary:
This diffs removes restrictions on selecting disabled, uninstalled and unsupported plugins. Now it will be possible to select them, however for now empty view will be shown in such case.
In next diffs I'll add Plugin Info view which will be shown in case disabled plugin is selected. It will show static info about plugin - readme, version, oncall, user feedback group etc. This will make it possible for users to browse info about all plugins, even unsupported by selected device/app.
There is one problem that our analytics will be screwed by this change as even disabled plugins will be counted as used. I'll address this later in this stack.
If you see other potential problems with removing restrictions on selecting disabled plugins - please let me know.
Reviewed By: passy
Differential Revision: D29186005
fbshipit-source-id: 2e55c5fd3bb402594f4dbace6e287725de65bc6f
Summary: This is purely refactoring change. Before that we computed plugin lists in-place in PluginList component. Now we will be re-computing them as side effect and will keep computed lists in redux. This makes it easier to re-use plugin lists in other places outside of PluginList component, e.g. in the upcoming Marketplace UI.
Reviewed By: mweststrate
Differential Revision: D29161719
fbshipit-source-id: 5cb06d4d8a553aa856101c78b2311fbc078c6bd7
Summary: I've modified migration to ensure it never produces "undefined" state. Before that this happened when migration is performed from version 0.75- to 0.77+ without 0.76 in between.
Reviewed By: mweststrate
Differential Revision: D26749830
fbshipit-source-id: 3a6599e80935060e8784103363abd617a7f1b7bd
Summary:
Fixes https://github.com/facebook/flipper/issues/1989
We had some self healing side effect that would destroy devices when registering a new device with the same serial, if they weren't yet. Redux isn't too happy about that, causing the attached crash.
Instead introduced a utility to destroy devices, and log an error if the device life cycle isn't respected by the device implementations, rather than crashing we will now just waste some memory.
Changelog: Fix a crash when disconnecting metro devices
Reviewed By: passy
Differential Revision: D26749214
fbshipit-source-id: 4c185ac521d44c1337fac8a9145440123b8b784c
Summary:
Fix for https://github.com/facebook/flipper/issues/1964
Changelog: fixed possible crash on startup after updating from a previous Flipper version to 0.77.0
Reviewed By: mweststrate
Differential Revision: D26664846
fbshipit-source-id: 6f9fabeaee8cfe1fa0df11bb57e27d659378a835
Summary:
Renamed actions "star" and "unstar" everywhere to "enable", "disable" and "switch". The logic behind original "star" action changed significantly, so this rename just makes everything much clearer.
Please note that as a part of rename persisted state fields "userStarredPlugins" and "userStarredDevicePlugins" were renamed. I've added a "redux-persist" migration for seamless transition.
Reviewed By: passy
Differential Revision: D26606459
fbshipit-source-id: 83ad475f9b0231194701c40a2cdbda36f02c3d10
Summary:
This is a very simple implementation of "profiles". It allows defining sets of plugins and associate them with GKs. Plugins from sets are automatically installed and enabled when a mobile app connected to Flipper for the first time (e.g. user has not already debugged same app before). Set is only enabled if user is passing the associated GK.
Sets are simply hardcoded for now.
Reviewed By: timur-valiev
Differential Revision: D26605371
fbshipit-source-id: 9bf0600d44381e047361d960558aa004960550c1
Summary: Enable device plugins by default to minimise breaking changes for users. Users will be able disable them if they want.
Reviewed By: mweststrate
Differential Revision: D26439227
fbshipit-source-id: 95c19e9335d583646c8aafd70a03e73bcf86c3bc
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*: implemented all plugin management actions for device plugins.
Changelog: it is now possible to enable/disable and install/uninstall device plugins
Reviewed By: mweststrate
Differential Revision: D26337377
fbshipit-source-id: 7d1ed61a8dc5f3339e5e548c613b67bca0c27f4f
Summary:
*Stack summary*: this stack refactors plugin management actions to perform them in a dispatcher rather than in the root reducer (store.tsx) as all of these actions has side effects. To do that, we store requested plugin management actions (install/update/uninstall, star/unstar) in a queue which is then handled by pluginManager dispatcher. This dispatcher then dispatches all required state updates.
*Diff summary*: refactored "star plugin" operation to perform it in pluginManager dispatcher.
Reviewed By: mweststrate
Differential Revision: D26305576
fbshipit-source-id: 90516af4e9ba8504720ddfa587f691f53e71b702
Summary:
*Stack summary*: this stack refactors plugin management actions to perform them in a dispatcher rather than in the root reducer (store.tsx) as all of these actions has side effects. To do that, we store requested plugin management actions (install/update/uninstall, star/unstar) in a queue which is then handled by pluginManager dispatcher. This dispatcher then dispatches all required state updates.
*Diff summary*: refactored "load plugin" operation to perform it in pluginManager dispatcher.
Reviewed By: mweststrate
Differential Revision: D26166654
fbshipit-source-id: e1fe48fa2cfc5533ad4f801ca56f00fc2ca3f4c4
Summary: Found some code duplication causing old devices not entirely to be cleaned up as they should
Reviewed By: nikoant
Differential Revision: D26422665
fbshipit-source-id: f57757f7260ac5de17edd80e9f66cc844d1a6213
Summary:
This diff introduces support for keeping clients around after they have disconnected. This is a pretty important debugging improvement, that will allow inspecting a device / app after it crashed for example.
With this diff, the current client is just kept around until it connects again, instead of throwing clients immediately away if they disconnect. After this change, ArchivedClients will only be created by imports / exports, and no longer by disconnects. Initially I played with improving the creation of archived devices, by migrating all plugin state over from the original client to the archive, but I discovered that is very prone, as it would be a lot of pointer redistribution (plugins would point to a different client / device etc). While in contrast, disconnected clients is already an existing concept in Flipper, so reusing that keeps all the changes relatively simple.
Note that we could potentially still reuse old clients around after reconnected, but it would become much harder to reason about how plugins would behave if they missed updates for a while, so throwing away the device / clients and starting with a fresh slate sounds safer. So I figured that chance to be too risky for now, but would probably be good follow up work.
Issues with import / export, UX, and making calls to to a disconnected client will be addressed in follow up diffs
Changelog: Clients will retain their state after being disconnected, until they reconnect again
Reviewed By: nikoant
Differential Revision: D26224677
fbshipit-source-id: feb9d241df2304341c2847fe7fd751ac54c045f6
Summary:
This diff stack introduces support for keeping devices and clients around after they have disconnected. This is a pretty important debugging improvement, that will allow inspecting a device / app after it crashed for example.
This feature existed partially before, but only supported Android, and only support plugins with persisted state; as it replace the current device with an archived version of the same device. In practice this didn't work really well, as most plugins would not be available, and all non-persisted state would be lost.
This diff makes sure we can keep devices around after disconnecting, the next one will keep the clients around as well. And explain some code choices in more detail.
Note that `Device.isArchived` was an overloaded term before, and even more now (both representing imported and disconnected devices), will address that in a later diff.
https://github.com/facebook/flipper/issues/1460https://github.com/facebook/flipper/issues/812https://github.com/facebook/flipper/issues/1487
Changelog: iOS and Android devices will preserve their state after being disconnected
Reviewed By: nikoant
Differential Revision: D26224310
fbshipit-source-id: 7dfc93c2a109a51c2880ec212a00463bc8d32041
Summary:
While trying to change something, discovered we have 3 different mechanisms in our code base to compute active plugins; the plugin list component, support form, and export flipper trace form had all their own, subtly different implementations of computing which plugins are available to the user.
Also removed some hardcoded exceptions for e.g. Logs plugin, which in the next diff and onward will be just a vanilla plugin without special casing
Unified that, which some how went a bit deeper than hoped, trough some hoops in in circular deps. Also unified to use the same testing utils, to avoid some gobbling objects manually together, with resulted in a bunch of unexpected NPEs. Found out that we actually still have unit tests using Flow in the process :-P. Converted one to TS.
Reviewed By: nikoant
Differential Revision: D26103172
fbshipit-source-id: 2fce2577d97d98543cb9312b3d013f24faee43aa
Summary: The default screen without any devices or magic GK's was a bit noisy, this diffs cleans it up
Reviewed By: jknoxville
Differential Revision: D25946004
fbshipit-source-id: 76b7eec16b433544e9872e726e8f57dd1ce02b0f
Summary:
This diff adds "download" button to the plugins shown in "Detected in App" section, so they can be downloaded, installed and enabled just in one click.
For now UI is very simple - there is no progress indication and no error handling for failed downloads. I'll add them in next diffs.
Please note that we are explicitly "star" every installed plugin to enable it straight away without additional clicks in "disabled" section.
Reviewed By: mweststrate
Differential Revision: D25393472
fbshipit-source-id: 0a224ea6d03db0ee9a70b7fa35ede9616c03d824
Summary:
Introduced API to replace the deprecated `selectPlugin` in Sandy.
The API can be used to navigate from `device plugin -> device plugin`, or` client plugin -> device / client plugin`
Introduced `isPluginAvailable` as well, so that the user interaction an be fine tuned in case the plugin is not disabled.
Reviewed By: jknoxville
Differential Revision: D25422370
fbshipit-source-id: c6c603f1c68e6291280b3d0883e474448754ded1
Summary:
FluxStores plugin of AdsManager didn't open on Sandy. The underlying reason is that in Sandy the list was based on the plugin id's as exposed in the `package.json`, while in the old left sidebar it was based on the `id` stored on the Plugin class. And apparently they can differ (will fix that in the next diff)
We can release an update of this plugin after it landed
Reviewed By: passy
Differential Revision: D25302357
fbshipit-source-id: 874aab263fad6a83f63edc4a8f7fa7ceceaef70f
Summary:
Some exploratory testing on all iOS and Android plugins, to see how they behave inside Sandy, and fixed some layout glitches (some were also present without Sandy)
General fixes:
* Introduced some niceties like searchbox resizing properly, and toolbars wrapping automatically in Sandy, rather than buttons becoming invisible
* Containers don't grow anymore by default, but take size of contents
* ScrollContainer child is now a Layout.Vertical. Layout.Vertical should be used as default container everywhere (e.g. Tabs, Panels) in the future
* Fixed layout issue if a split container had only 1 visible child
* DetailsSidebar now scrolls vertically by default
* Details sidebar would sometimes render content in-place rather than in the reserved area
* AppSelector dropdown and Plugin list will now properly ellipse (...) if there is not enough space
Plugin fixes:
* Long database / table names in Database plugin would break layout
Also fixes https://github.com/facebook/flipper/issues/1611
Reviewed By: passy
Differential Revision: D24454188
fbshipit-source-id: c60c867270900a1d4f28587d47067c6ec1072ede
Summary:
This adds the ability in AppInspect to work with Metro and plugins.
Metro remains a weird and hardcoded edge case, as we show it as part of another device. So a few things to notice:
- Metro does not have it's own entry in the device/app dropdown
- When selecting a metro plugin, the surrounding context (selected main device / app) remains, but you will notice that the device dropdown switches to 'React Native'. This is intentional to reflect that we are talking to React Native in general, and not necessarily to the device / app shown in the context.
Reviewed By: nikoant
Differential Revision: D24422267
fbshipit-source-id: 239aa71b5c01e19bdda53a930ad9fa8af13b8d4a
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:
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:
Handling issues typically start with: did you look at the Electron logs? Since Flipper is such an extensible tool, running in varying environments I think the console should be support as first class concept. Many errors are currently not shown to the user. This PR is a first attempt to fix that.
The implementation is based on https://github.com/samdenty/console-feed, which is used by quite some web based IDE like tools (like codesandbox), and offers a lot of goodies out of the box, like collapsing errors, objects, etc.
Edit: also added a counter keeping track of the amount of errors
N.B. no need to immediately review this diff, I'll import it to phabricator as soon as I can :)
## Changelog
changelog: Introduce 'Debug Logs' section to help users to troubleshoot issues or to provide more accurate reports.
Pull Request resolved: https://github.com/facebook/flipper/pull/1479
Test Plan: 
Reviewed By: jknoxville
Differential Revision: D23198103
Pulled By: passy
fbshipit-source-id: a2505f9fa59e10676a44ffa33312efe83c7be55d
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: 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:
This diff makes sure that devices will actually instantiate applicable sandy device plugins. Similar to how client plugins are owned by Client, device plugins are directly owned by BaseDevice, which significantly simplifies life cycle management and doesn't dispatch updates to all Redux connect components whenever something irrelevant changes.
Also made sure `device.teardown()` is called. That API already existed, but wasn't used or implemented before.
Updated Flipper test utils to support testing device plugins as well (both Sandy and classic ones)
Reviewed By: passy, nikoant
Differential Revision: D22693929
fbshipit-source-id: 73b2b8666ef7a0e748ea89360db84734d37eb5be
Summary:
This adds support for handling incoming deeplinks in a Sandy plugin, which can be done by using a `client.onDeepLink(deepLink => { } )` listener
Also generalized deeplinks to not just support strings, but also richer objects, which is beneficial to plugin to plugin linking.
Reviewed By: jknoxville
Differential Revision: D22524749
fbshipit-source-id: 2cbe8d52f6eac91a1c1c8c8494706952920b9181
Summary:
While writing unit tests discovered a bug that disabling a plugin doesn't guarantee cleaning the messagequeues (both the buffer in client and the messagequeue reducer).
Fixed that. That was thanks to @#%@#$@#%@ Redux a lot harder than it should be; as 'STAR_PLUGIN' reasons about a plugin + app name, while the message queue reducer would need to deduct the plugin keys from that, but it can't because that mapping is stored in the connections reducers. So I moved the `STAR_PLUGIN` action handling to the root reducer, sot that it can reason about the state of multiple reducers, which looked like the least of all evils. For more ranting about that and possible alternative solutions: https://twitter.com/mweststrate/status/1277556309706117122
Reviewed By: nikoant
Differential Revision: D22284043
fbshipit-source-id: 35d0a8ba3a21a5959d2bb6ef17da3ff5077f48fd
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:
This diff makes sure sandy plugins are initialized.
Sandy plugins are stored directly in the client for two reasons
1. we want to decouple any plugin state updates from our central redux store, as redux is particularly bad in handling high frequency updates.
2. The lifecycle of a plugin is now bound to the lifecycle of a client. This means that we don't need 'persistedStore' to make sure state is preserved; that is now the default. Switching plugins will no longer reinitialize them (but only run specific hooks, see later diffs).
3. PersistedState will be introduced for sandy plugins as well later, but primarily for import / export / debug reasons.
A significant difference with the current persistent state, is that if a client crashes and reconnects, plugins will loose their state. We can prevent this (again, since state persisting will be reintroduced), but I'm not sure we need that for the specific reconnect scenario. Because
1. we should fix reconnecting clients anyway, and from stats it looks to happen less already
2. reconnects are usually caused by plugins that aggregate a lot of data and get slower over time. Restoring old state also restores those unstabilites.
For the overview bringing back the archi picture of earlier diff:
{F241508042}
Also fixed a bug where enabling background plugins didn't enable them on all devices with that app.
Reviewed By: jknoxville
Differential Revision: D22186276
fbshipit-source-id: 3fd42b577f86920e5280aa8cce1a0bc4d5564ed9
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:
Part of https://github.com/facebook/flipper/issues/262
Use the user-configured idb install location instead of a hardcoded one.
Reviewed By: passy
Differential Revision: D21860236
fbshipit-source-id: 5c604d7b6361e7c93ab49d8a03a437dfce880ac1
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
Summary:
This diff fixes an issue where we don't want to have the Navigation plugin be disabled as background plugins like all other plugins, so that the breadcrumb navigation keeps working.
Yet another hack concerning the super useful Navigation plugin. On a positive note, since connection management for background is not entirely managed by the Desktop and not the native said, these kind of exceptions are fairly easy to make :)
Reviewed By: passy
Differential Revision: D21089537
fbshipit-source-id: 209954ff35c95e066fe688a60ad46ccfc3835c44
Summary:
Background for this diff: https://fb.quip.com/KqEfAlKYlgme
Some plugins don't respect that stuff (livefeed and graphql), but for others it seems to work fine.
This is just a PoC, there are some present bugs concerning the combination of selecting and bg plugins
Questions to investigate:
- [x] make sure that LiveFeed and GraphQL disconnect properly. There might be more plugins that need that
- [x] verifiy that we don't loose one of the original goals of background plugins, e.g. QPL collecting and sending data from device start. Does this still work as intended after this change?
- [x] how can we observe / measure improvements? Are dev builds more responsive after this? Is the layout inspector smoother for example because no QPL plugins are interweaved?
- [x] how is forward and backward compatibility?
- If Flipper is updated, but device not: No change I think, as getBackgroundPlugins() will return an empty set, and background plugins are initiated as usual, so old behavior
- If device is updated, but Flipper not, background plugins won't be started until they are selected. This is a degradation, but hopefully explainable.
- [x] Verify QPL buffer is not unbounded
- [x] Share architecutre changes with team
For Graphql updates: D20943455
Added runtime stats to monitor network traffic (sadly had to redo that since scuba couldn't handle the data format used at first, so probably will hold of landing this diff a week to make sure we can see some effects)
Follow up work:
[x] wait until we released the stat tracking before we release this, to be able to measure the effect?
[x] make sure graphql fix lands
[ ] use side effects abstraction
[ ] fix other background plugins (android only) or fix it in a generic way:
{F234394286}
Changelog: Background plugins will no longer receive a Flipper connection if they are disabled. This should significantly reduce the overall load of Flipper both on the device and desktop when unused plugins are disabled used, which could otherwise generate 10MB/s of network traffic certain scenarios. All plugins *should* be able to handle to this gracefully, but since this is quite a fundamental change, reach out to the Flipper team when in doubt!
Reviewed By: jknoxville
Differential Revision: D20942453
fbshipit-source-id: b699199cb95c1b3e4c36e026b6dfaee7d1652e1f
Summary:
This diff fixes an issue where the selected device was not correctly updated when selecting a device plugin, causing the wrong plugin, or none at all, to be highlighted.
This diff fixes an issue where deeplinks were not correctly parsed if formatted as shown in the test plan of D20920587 (it was a different format in the recording, but after looking into it, using `plugin?params` instead of `plugin/?params` is the natural thing to do, so we now support both)
Reviewed By: jknoxville
Differential Revision: D21154190
fbshipit-source-id: c31132aaf7213ee1c3c188a6a1cf2b6bcc7b5b00
Summary: Allow optionally to provide the device title to select a plugin in. Currently, there's only support for `flipper://<app>/<plugin_id>`. This allows to add a `?device=<specifier>`.
Reviewed By: mweststrate
Differential Revision: D20920587
fbshipit-source-id: e7df4b510f1adfa9c2c9d072f6aebca1edb89cc0
Summary:
Quick notes:
- This looks worse than it is. It adds mandatory parentheses to single argument lambdas. Lots of outrage on Twitter about it, personally I'm {emoji:1f937_200d_2642} about it.
- Space before function, e.g. `a = function ()` is now enforced. I like this because both were fine before.
- I added `eslint-config-prettier` to the config because otherwise a ton of rules conflict with eslint itself.
Close https://github.com/facebook/flipper/pull/915
Reviewed By: jknoxville
Differential Revision: D20594929
fbshipit-source-id: ca1c65376b90e009550dd6d1f4e0831d32cbff03
Summary: Fixed circular dependency warnings and removed some dead code while at it.
Reviewed By: jknoxville
Differential Revision: D20557313
fbshipit-source-id: 856c42113a9abe36d3e14f9d538eb40705ceb87f
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1
