Summary:
Bumps [js-base64](https://github.com/dankogai/js-base64) from 3.5.2 to 3.6.0.
<details>
<summary>Commits</summary>
<ul>
<li><a href="ad8897c84b"><code>ad8897c</code></a> version 3.6.0</li>
<li><a href="78016271df"><code>7801627</code></a> add isValid()</li>
<li>See full diff in <a href="https://github.com/dankogai/js-base64/compare/3.5.2...3.6.0">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1935
Reviewed By: mweststrate
Differential Revision: D26463175
Pulled By: passy
fbshipit-source-id: 06b223e8d89c75f5bda1e67b4e41403f7663ec7e
Summary: Show warnings for the device plugins defined in the legacy format and suggest to migrate them
Reviewed By: mweststrate
Differential Revision: D26459321
fbshipit-source-id: 4e45cd58a63a4ff9903ecaf12e6f9ba4a43e71e1
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:
Added option to bootstrap device plugin in "flipper-pkg".
Changelog: "flipper-pkg init" can now be used to bootstrap device plugins
Reviewed By: mweststrate
Differential Revision: D26389429
fbshipit-source-id: 90773011bd50289004cd747111e1787402840922
Summary: Now as we can install device plugins from Marketplace, I was able to unbundle device plugins which were used quite rarely, but still added ~3 MB to the final Flipper bundle.
Reviewed By: mweststrate
Differential Revision: D26337297
fbshipit-source-id: 23a36cc15ca976a1215440192718d985e1f322fd
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 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:
*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:
*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 "uninstall plugin" operation to perform it in pluginManager dispatcher
Reviewed By: mweststrate
Differential Revision: D26166198
fbshipit-source-id: d74a1d690102d9036c6d3d8612d2428f5ecef4e6
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 Flipper mocking helpers to allow testing of plugin commands, and wrote some tests for pluginManager.
Reviewed By: mweststrate
Differential Revision: D26450344
fbshipit-source-id: 0e8414517cc1ad353781dffd7ffb4a5f9a815d38
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*: implemented basic plugin action queue processing.
Reviewed By: mweststrate
Differential Revision: D26164945
fbshipit-source-id: 5d8ad9b4d7b1300e92883d24a71da9ca1f85b183
Summary:
I don't think there's an easy way to do this based on types
which would be ideal ...
So instead I'm checking for
- Importing `remote` from `electron`.
- Accessing `electron.remote`.
You can still hack this by importing `electron`, saving
it to a differently named variable and accessing `remote` on it,
but this should cover all reasonable cases we see in real code.
Reviewed By: mweststrate
Differential Revision: D26453006
fbshipit-source-id: 4b3d223bed43ca3f0d1a4f592ea8f8060a823479
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:
Changelog: Fixed issue where a Flipper crash would result in an entirely blank screen, rather than a useful error message.
While debugging another issue, discovered that React errors that happen outside a Plugin aren't caught at all, resulting in the infamous gray screen of deaths. This was the case because no error boundary has been set up for our Chrome, and since React 16 the default error handling has becoming rendering blank, rather than freezing. See https://reactjs.org/docs/error-boundaries.html#new-behavior-for-uncaught-errors.
Thanks to ant.design styling this decently was trivial :). But sadly involved a component class since error boundaries are not yet available as hook.
With these changes the errors should also end up more readably in our monitoring.
Reviewed By: nikoant
Differential Revision: D26422666
fbshipit-source-id: 6c0f8611c80a4a5e0d7e61d58afcf5eabe410e57
Summary:
T84629221 shows this is quite common and is not something we want
to log errors for.
Reviewed By: mweststrate
Differential Revision: D26371400
fbshipit-source-id: 748a83d8ad484b0ceb1f3bf7e3a447602ae4c961
Summary:
This is our #1 error and always means there's something off with
the user's setup.
Reviewed By: mweststrate
Differential Revision: D26370974
fbshipit-source-id: 5e2644ce9de8a7d28614a22fab5ce54dab0561d3
Summary:
Adding context everywhere as naked messages are hard to track down
and making common errors like missing Xcode license agreements
a warning + error popup instead.
Changelog: Reduce spamminess of iOS connection warnings
Reviewed By: mweststrate
Differential Revision: D26370235
fbshipit-source-id: b283d297479c2bf76a11b5a3f96a59fad70a4a67
Summary: Noticed in the support group that the imported device label was incorrect. Probably a copy paste error.
Reviewed By: nikoant
Differential Revision: D26368664
fbshipit-source-id: abc2aad4d20a9f44d6f1ac45962ab28863d78f0d
Summary:
Bumps [types/socket.io](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/socket.io) from 2.1.11 to 2.1.13.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/socket.io">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1910
Reviewed By: mweststrate
Differential Revision: D26341340
Pulled By: passy
fbshipit-source-id: aaa780ca9a3e5c7ca082818e7462b02abca373fa
Summary:
Bumps [types/react-test-renderer](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/react-test-renderer) from 16.9.3 to 17.0.0.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/react-test-renderer">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1906
Reviewed By: mweststrate
Differential Revision: D26341261
Pulled By: passy
fbshipit-source-id: 09baa342878dcf31874635371fd63b8298a1581e
Summary:
Network calls are normally unique to an application as are the associated mocks. Currently, the mocks for different applications are combined together and saved to the local store. It would be better if mocks were saved (and retrieved by application).
This PR adds "appId" to the local store name to save mocks separately for each app. This is not really the ideal technique since different apps could have the same name. Android apps use packageId rather than app name (which is what appid is) to uniquely identify an app. However, package id does not seem to be available to the Flipper client so appid is used instead.
This requirement is described in this issue: https://github.com/facebook/flipper/issues/1487
Also, individual developers often have a preference for how they like to view response data (parsed or formatted). This PR saved the selected format so that the developer does not have to keep selecting it. Since this preference is not specific to an app, it is not necessary to save the preference for each app.
## Changelog
Network plugin - save mocks by app
Network plugin - save response body format preference to local storage
Pull Request resolved: https://github.com/facebook/flipper/pull/1871
Test Plan:
Install two apps (with different names)
Create mocks in each app
Restart Flipper
View the mocks for each app and verify that they are unique to the app
Reviewed By: mweststrate
Differential Revision: D26341333
Pulled By: passy
fbshipit-source-id: cc0286a9dc4e37e008672bfad7c6180f0d5675e4
Summary:
I want to use TypesScipt type literals in a next diff (e.g.
```
type Percentage = `${number}%`
```
But to be able to use that typescript, prettier and eslint needed bumps :)
Reviewed By: nikoant
Differential Revision: D26321133
fbshipit-source-id: a4891246ef8c654f324c6daf303c5c4b2f54496e
Summary:
Some minor loose ends from exploratory testing:
- disconnect device logs event listeners if the device disconnects
- show metro if that is still up, even if the app is no longer connected
- hide the options in the support form to record videos / screenshots if the device isn't connected
Reviewed By: nikoant
Differential Revision: D26277100
fbshipit-source-id: 49d0c934d587b226bc25524224efce60b53939e9
Summary:
Per title, if a plugin makes a client call, show a quick notif so that the user knows why his plugin interactions aren't responding in case the plugin doesn't use `isConnected` guards.
This might turn out to be too spammy, but I think it should be ok.
Reviewed By: nikoant
Differential Revision: D26277099
fbshipit-source-id: bd555ea84acae6189ec7f8fff0fc0a088dbc5337
Summary:
Previously, plugins could relatively safely use `client.call` at any moment in time to fetch some information from / to the client. Except for some raise conditions there was generally speaking a connection available.
With this stack it becomes possible to interact with plugins even after an app (unexpectedly) disconnected, which makes Flipper a lot more versatile, especially when it comes to inspect crashes post mortem. (For more explanation see the second diff in this stack)
However, this means that it is no longer safe to assume there is always a connection available. For that reason `client.isConnected` has been introduced to safeguard against that.
This diff introduces guards on all user interactions that are not super explicitly triggered by the user to avoid a lot of errors being generated. This is mostly in `init()` blocks and implicit user events like selecting or hovering rows.
Explicit user interactions like pressing buttons are not guarded by this diff, as ideally failure to communicate with the client should be communicated back to the user more explicitly rather than failing silently. The next diff will introduce a fallback mechanism where a popup is shown in case those calls aren't guarded.
Fixed a few key warnings while at it.
Reviewed By: nikoant
Differential Revision: D26275604
fbshipit-source-id: 5630066cdd9541e448a6dd1f8a21861b5d751ced
Summary:
Minor code cleanup to avoid future confusion:
- archived: a device that was imported from a Flipper trace, and only has persisted state
- (dis)connected: a real stateful device that might or might not have an active connection
Reviewed By: nikoant
Differential Revision: D26275459
fbshipit-source-id: eba554b37c39711e367c3795ff4456329a303c22
Summary:
This diff addresses two problems:
1. Since clients plugins can be active beyond having a connection, we have to make it possible for plugin authors to check if they are connected before they make a call.
2. if there is a custom `exportPersistedState`, plugins should be able to skip making calls if the device has disconnected.
Introducing this change makes it possible to interact with a reasonable level with disconnected clients, and makes it possible to create Flipper traces for disconnected clients.
Note that both items were already problems before supporting offline clients; as there can be a noticeable delay between disconnecting and Flipper detecting that (i've seen up to 30 secs). What happend previously in those cases is that the export would simply hang, as would other user interactions, as loosing the connection in the middle of a process would cause the promise chains to be neither rejected or resolved, which is pretty iffy.
Before this diff, trying to export a disconnected device would hang forever like:
{F369600601}
Reviewed By: nikoant
Differential Revision: D26250895
fbshipit-source-id: 177624a116883c3cba14390cd0fe164e243bb97c
Summary:
During testing I noticed that even though plugin queues were flushed, the processed messages didn't end up in the export snapshots. This was caused by holding a ref of an older snapshot of the state
Changelog: Fixed an issue where data that arrived in the background was not part of the generated Flipper export.
Reviewed By: nikoant
Differential Revision: D26250897
fbshipit-source-id: ddd3f5bb19e38a1b13498d03f235bf63858eb8f8
Summary:
Small UX improvement, try to select a newly arriving client if possible, this is nice as it means that disconnecting and connecting will typically end you up in the same app.
Changelog: If a new client connects, Flipper will try to focus on it
Reviewed By: nikoant
Differential Revision: D26250896
fbshipit-source-id: 83d9777a8608cd887d663a6bbe1444d2aa614e95
Summary:
It should be possible to exported disconnected devices, so that flipper traces / support form reports can be created from them. This diff introduces this functionality. Support for plugins with custom export logic is introduced in a later diff.
Issues fixed in this diff:
- don't try to take a screenshot for a disconnected device (this would hang forever)
- device plugins were always exported, regardless whether the user did select them or not
- sandy plugins were never part of exported disconnected clients
- increased the amount of data exported for device logs to ~10 MB. This makes more sense now as the logs will no longer be included in all cases
- fixed issue where are plugins would appear to be enabled after the client disconnected (this bug is the result of some unfortunate naming of `isArchived` vs `isConnected` semantics. Will clean up those names in a later diff.
Changelog: It is now possible to create a Flipper trace for disconnected devices and apps
Reviewed By: nikoant
Differential Revision: D26250894
fbshipit-source-id: 4dd0ec0cb152b1a8f649c31913e80efc25bcc5dd
Summary: UX love for imported and disconnected devices, so that stuff looks better :)
Reviewed By: nikoant
Differential Revision: D26249348
fbshipit-source-id: 70db682ccf0cb73161e136994f5135717f3c6be6
Summary:
Introduced `isConnected` flag on device and plugin client to reflect whether a connection is still available for the plugins, or that they have been disconnected.
Potentially we could expose the (readonly) `connected` state atom for this as well, or an `onDisconnect` event for device pugins, to create a responsive UI, but there might be no need for that, in which case this suffices.
Reviewed By: nikoant
Differential Revision: D26249346
fbshipit-source-id: b8486713fdf2fcd520488ce54f771bd038fd13f8
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:
Changelog: CPU plugin will no longer show up for archived devices
CPU plugin did show up on imported devices, but would always result in exceptions as no `adb` connection is available for them.
Reviewed By: jknoxville
Differential Revision: D26249575
fbshipit-source-id: c4fa7b3fec895f9c4ab9e31dce2f61fb23e9195b
Summary:
The any type was masking how the log object is actually initialised.
Sorry for the deluge of drive-by diffs. Something more substantial is coming.
Reviewed By: mweststrate
Differential Revision: D26250580
fbshipit-source-id: 5ba3f450ac1a646616868a8fd8b3cb42fb14dcc8
Summary:
There's a bit of an oddity with `idb` that the `stream` parameter is implied even though the docs say otherwise and if you try to use it, it'll give you a strange Python error. That's likely why we never implemented it.
Now, it works just as it does using local tooling.
Reviewed By: mweststrate
Differential Revision: D26228036
fbshipit-source-id: e20cb31167170ba0501e2929ed129305cb9aaf2c
Summary: The "attaching failed" error provides no context and is a handled error, so we don't need to elevate this to a warning. We also see a socket warning on stderr every time we start up logging through simctl, so we don't need to treat that as an error.
Reviewed By: nikoant
Differential Revision: D26228037
fbshipit-source-id: 1938dadd54499462e1fd614c9477f738661c387b
Summary:
VSCode got a new thing where it doesn't save my file because it waits for a formatter or some stuff indefinitely, which is really cool, because it means my diffs end up being incomplete.
So this should have been in D26223274 (642d89213d) but now it's here.
angry_cry
Reviewed By: nikoant
Differential Revision: D26228038
fbshipit-source-id: 98b84179dce4e8e8c71f9196ab78d534327ea301
