Commit Graph

16 Commits

Author SHA1 Message Date
Michel Weststrate
5df34a337c Unshare global types
Summary:
This diff adds `types` fields on the compiler config for every project. This way we can make sure that for example node types and packages are not available in flipper-ui-core. Without an explicit types field, all types would be shared between all packages, and implicitly included into the compilation of everything. For the same reason `types/index.d.ts` has been removed, we want to be intentional on which types are being used in which package.

This diff does most of the work, the next diff will fine tune the globals, and do some further cleanup.

As an alternative solution I first tried a `nohoist: **/node_modules/types/**` and make sure every package list explicitly the types used in package json, which works but is much more error prone, as for example two different react types versions in two packages will cause the most unreadable compiler error due to the types not being shared and not literally the same.

Reviewed By: lawrencelomax

Differential Revision: D33124441

fbshipit-source-id: c2b9d768f845ac28005d8331ef5fa1066c7e4cd7
2021-12-17 07:36:07 -08:00
Michel Weststrate
dcfeb4a4d5 Clean up packages and types
Summary:
This diff removes most deps from the root package.json, which now only contains electron and shared build / test infra structure: lint, prettier, jest, typescript.

This makes it possible to control much better which packages are used where, as all sub packages now have their deps explicitly in their package.json instead of incidentally shared. This allows for example to disable DOM types for all packages by default (flipper-plugin, ui(-core) and app still request it), and in the next diff I hope to add to this that nodeJS types are no longer shared either, so that UI oriented packages will generate compile errors when using Node built-ins

This diff removes most deps that were currently unused, and dedupes a bunch of other ones, so the build should probably be a bit smaller now as well:

{F686704253}

{F686704295}

Reviewed By: antonk52

Differential Revision: D33062859

fbshipit-source-id: 5afaa4f2103d055188382a3370c1fffa295a298a
2021-12-16 14:54:59 -08:00
Michel Weststrate
7e50c0466a Move app/src (mostly) to flipper-ui-core/src
Summary:
This diff moves all UI code from app/src to app/flipper-ui-core. That is now slightly too much (e.g. node deps are not removed yet), but from here it should be easier to move things out again, as I don't want this diff to be open for too long to avoid too much merge conflicts.

* But at least flipper-ui-core is Electron free :)
* Killed all cross module imports as well, as they where now even more in the way
* Some unit test needed some changes, most not too big (but emotion hashes got renumbered in the snapshots, feel free to ignore that)
* Found some files that were actually meaningless (tsconfig in plugins, WatchTools files, that start generating compile errors, removed those

Follow up work:
* make flipper-ui-core configurable, and wire up flipper-server-core in Electron instead of here
* remove node deps (aigoncharov)
* figure out correct place to load GKs, plugins, make intern requests etc., and move to the correct module
* clean up deps

Reviewed By: aigoncharov

Differential Revision: D32427722

fbshipit-source-id: 14fe92e1ceb15b9dcf7bece367c8ab92df927a70
2021-11-16 05:29:21 -08:00
Michel Weststrate
c3ff0ff355 Set up Flipper decapitated packages
Summary:
This diff introduces the packages necessary for Flipper decapitated.

* flipper-common: utilities & types shared between client, server, flipper-plugin
* flipper-server-core: all device & client management goes in here. Basically flipper's backend
* flipper-ui-core: all UI goes in here, as far as it doesn't depend on Electron
* desktop: the Electron app, will load server-core and ui-core, and glue them together, providing implementations for some electron specific stuff like dialgos
* flipper-server: A node process hosting flipper-server-core, that can be connected to over websockets. And probably can serve a browser version of the UI as well.
* flipper-ui-browser: thin wrapper around flipper-ui-core, providing some browser specific behavior / stubs.
* flipper-dump: (might remove later), but want to hack a quick and dirt flipper dump in here, as alternative way to test flipper-server-core.

This diff just creates the packages, but doesn't move any code, so it can be summarized as:

restoftheowl

Reviewed By: nikoant

Differential Revision: D30218646

fbshipit-source-id: 735598a1261a98e584f52504b5eba01ec0afa162
2021-10-08 01:33:03 -07:00
Michel Weststrate
75b5783fd0 Clean up QPL integration
Summary:
Removed the Flipper QPL integration, see:
https://fb.workplace.com/groups/flippersupport/permalink/1200183003795689/

It complicates our build setup significantly, without actually being used anywhere for the past year. Apparently it doesn't solve a gap compared to the scuba logging we have already in place.

Reviewed By: passy

Differential Revision: D30911573

fbshipit-source-id: 836e2aba0c92c0eed9fed0dfb12bd8bdcb8c7d71
2021-09-14 02:55:01 -07:00
Michel Weststrate
1a91dc53fd Upgrade TS to 4.4
Summary: per title. TS 4.4 is awesome btw, with the much improved control flow analysis.

Reviewed By: timur-valiev

Differential Revision: D30806769

fbshipit-source-id: a41aa7bf10fdb0047ddb6210082b5e1fbdfb255f
2021-09-08 09:59:38 -07:00
Anton Nikolaev
04c5fb61f4 Rollback removing paths from tsconfig.json
Summary: Returning back paths config in tsconfig.json which I removed recently. Without them typescript compilation is required when exported APIs changed in dependency packages, e.g. in "flipper-plugin", otherwise lint/tests fails. So it's better to keep them for convenience.

Reviewed By: mweststrate

Differential Revision: D27619748

fbshipit-source-id: bb5929526ee2bf6bd06a5f15dbf898b7ca6deea7
2021-04-07 08:31:04 -07:00
Anton Nikolaev
f468f0e07d Produce tsc typings for "flipper" package
Summary: This diffs refactors tsc projects structure and structure of our custom typings to allow producing typescript typings for "flipper" package. In next diffs I'm going to use the produced typings to check compatibility of plugins with certain versions of Flipper, e.g. to check whether plugin is compatible with current "stable" and "insiders" version.

Reviewed By: passy

Differential Revision: D26997158

fbshipit-source-id: a0416c7139bf08ec9d175730da4c4c2a8768eeb7
2021-03-17 14:03:38 -07:00
Edward Yerburgh
8a31e984b3 Use QPL-managed QPLCore and PigeonClient (#1612)
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1612

* Use the QPL-managed QPLCore and PigeonClient.

**Facebook:**

js-shared/qpl and js-shared/pigeon-client are maintained by QPL in xplat/js-shared. I've updated the Metro config and tsconfig to allow the packages to be imported without breaking the open-source version.

Reviewed By: passy

Differential Revision: D24358369

fbshipit-source-id: 7f13d6c99d8ca6ebcd0e66bf0e5f25069370cce7
2020-10-26 02:29:09 -07:00
Anton Nikolaev
4a1c2a9ece Custom eslint rule for disallowing cross-package references
Summary:
Added infra for writing and using custom eslint rules and created a rule for disallowing cross-package file imports. Such imports are anti-pattern and they also break standalone plugin bundling.

We still have a bunch of places where Flipper core references code directly from plugins. I've ignored these places for now and added task T71355623 to revisit them.

Reviewed By: passy

Differential Revision: D22998955

fbshipit-source-id: d04cff8fc115ba1300a7e6830306ec134046e927
2020-08-07 10:22:04 -07:00
Michel Weststrate
0e4a6d659b Make sure plugins can serialize and deserialize
Summary:
This plugin adds serialization capabilities to Sandy plugins buy setting the a `persist: <key>` flag. This shouldn't be used for state that is unserializable, too big, too sensitive, or irrelevant during export / import.

Using an explicit `persist` flag is done to make plugins robust to changes over time; as long as the key is kept the same, state variables can be renamed and reordered without breaking the import / export format. Also it allows us to detect some changes in the import / export format and warn about it.

Alternative designs considered but not implemented would be:
1. requiring the user to explicitly return the state from the factory (e.g. `const todos = createState([]); return { todos }`,
2. or construct the state from client (e.g. `const todos = client.createState([])`)
3. enable persistence by default, and store states in the order the states were created (much like useState in React). This was implemented in the first versions of this diff, but as pointed out in the discussions, this is too sensitive too (accidental) format changes, as the storage format would be quite implicit

A nice benefit of the current approach, especially compared with alternative approach 1, is that state being restored is immediately visible in the plugin factory. In other words, directly after initialization `const todos = createState([])`, the `todos.get()` is actually set to the state that is being restored, rather than having still the initial state which is only overridden rather. So this behaves very much like the `useState` hook in React.

Furthermore, in the future we could use the same `persist` key in combination with other options, such as `saveToLocalStorage`, in case some state acts as a 'preference' (T69989583).

`TestUtils.startPlugin` supports starting plugins with an initial state by using the optional `initialState` field

Actually wiring up the serialization and deserialization into the export / import functionality of Flipper is done in the next diff.

Reviewed By: jknoxville

Differential Revision: D22432770

fbshipit-source-id: 9a4849582c2f6f54d1e40f65a6cba73092c28fe8
2020-07-14 09:06:59 -07:00
Michel Weststrate
2383dc85f8 Initialized flipper-plugin library
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
2020-07-01 09:12:35 -07:00
Anton Nikolaev
ecfdeb2276 Make external typings re-usable across all the workspaces
Summary: Our external typings were only effective for the main "app" package. In this diff I've made them effective for all other workspaces too, and also cleaned up typescript configs.

Reviewed By: passy

Differential Revision: D21927361

fbshipit-source-id: ceb8009255583d969d79cc11b20dfe8b686f2fb3
2020-06-08 08:57:06 -07:00
Anton Nikolaev
9e3b57bea7 Remove "incremental" option from base tsconfig
Summary: "incremental" option in base config conflicts with "tsc --noemit" which leads to crashes like in D21155831. Removing it from base config, anyway it is explicitly set for all the packages where required (babel-transformer, pkg-lib, pkg)

Reviewed By: timur-valiev

Differential Revision: D21157205

fbshipit-source-id: bb37101521d865bbe737e99637a9bc83a308494e
2020-04-21 10:19:53 -07:00
Anton Nikolaev
c1bb656a0d Re-use babel transformations
Summary:
SORRY FOR BIG DIFF, but it's really hard to split it as all these changes are cross-dependent and should be made at once:
1. Moved transformations to separate package "flipper-babel-transformer" and linked it using yarn workspaces to "static" and "pkg" packages where they are re-used. Removed double copies of transformations we had before int these two packages.
2. Converted transformations to typescript
3. Refactored transformations to avoid relying on file system paths for customisation (FB stubs and Electron stubs for headless build)
4. As babel transformations must be built before other builds - enabled incremental build for them and changed scripts to invoke the transformations build before other build scripts
5. As we need to deploy all the dependencies including the fresh "flipper-babel-transformer" as a part of "static" - implemented script which copies package with all the dependencies taking in account yarn workspaces (hoisting and symlinks)

Reviewed By: passy, mweststrate

Differential Revision: D20690662

fbshipit-source-id: 38a275b60d3c91e01ec21d1dbd72d03c05cfac0b
2020-03-27 03:26:51 -07:00
Anton Nikolaev
06cd90562d Re-use base tsconfig options
Summary: Added tsconfig.base.json and extend other tsconfigs from it.

Reviewed By: passy

Differential Revision: D20594653

fbshipit-source-id: 28dd80262613e78a7c4ce25fa31f251537ec2b06
2020-03-23 05:40:34 -07:00