Summary:
Currently we download a bunch of FB icons and we normally use the smallest one available.
In this diff I change the download logic so we try to download from the largest to the smallest icon and use the first one available. One the client we no longer provide the icon of the same size that is requested, instead we provide the only one we have which will typically be larger than needed. This is a good thing because
1. flipper is a local application and we do not need to worry about icons take up broadband and downloading
2. People have high density displayed
I also stopped using density(rest of related code removed in the next diff) for icons as it the icons themselves did not support it.
Reviewed By: lblasa
Differential Revision: D50495194
fbshipit-source-id: f569c2f3b8ee424a67c6d21136e7e113868b8f6a
Summary: As we stopped bundling plugins in D39276249, we no longer need the entry points for the bundled plugins (these entry points are always going to be empty)
Reviewed By: lblasa
Differential Revision: D39307565
fbshipit-source-id: 43751fe31c8bd962677c226b27cfe52093d3f2d4
Summary:
CHANGELOG: Rotate flipper-server logs
Otherwise, they re going to eat up all space eventually in a one monstrous file
Reviewed By: passy
Differential Revision: D37516868
fbshipit-source-id: 478a61c56ec007e4a3d695f7e6df2a61cb33c33a
Summary: Flipper Server Companion starts headless plugins and exposes them over the wire
Reviewed By: passy
Differential Revision: D36098170
fbshipit-source-id: 3b1b077d1fa4adca5c340ad4475b80b229586e1b
Summary:
This diff makes flipper-server stand-alone servable as a single package.
It basically works as follows:
- (default) plugins are build as usually into static folder
- static folder is copied into flipper-server/static (as far as relevant)
- `flipper-server/src/index.tsx` is bundled into `flipper-server/dist/index.js`
- `flipper-ui-browser/src/index.tsx` is bundled into `flipper-server/static/bundle.js`
If flipper-server is started without the `--bundler` config, the `bundle.js` will be served statically, rather than starting up the Metro bundler with all the typical transforms (in a distributed version of the package those all wouldn't resolve)
Things to be done in next diffs:
* make sure plugins actually load in the non bundled setup
* make sure flipper-server gets published properly
* make sure build is created as part of CI
At the end of this stack, running `npx flipper-server` on any machine should basically be a viable approach to get flipper up and running locally :)
Reviewed By: nikoant
Differential Revision: D33171107
fbshipit-source-id: 4af8ac2699467a0b55283fe084640482700744c2
Summary:
Bundled plugins so far didn't load because the defaultPlugins was not generated yet. Fixed follow up errors that resulted from node modules not being available in the browser, and made the process more robust so that one plugin that fails to initialise doesn't kill all bundled plugins from being loaded.
Cleaned up the server scripts, and reused the BUILTINS list that is already maintained in the babel transformer.
Report errors during the build process if modules are referred that are stubbed out (later on we could maybe error on that)
Reviewed By: aigoncharov
Differential Revision: D33020243
fbshipit-source-id: 3ce13b0049664b5fb19c1f45f0b33c1d7fdbea4c
Summary:
The build process for the server was a simple ts-node that compiled all deps. However, that didn't do any source transformations we need, like replacing `fb-stubs` with `fb` in facebook builds.
This diff works out the dev build process to align more with how other parts of the code base is build, by starting metro to build and bundle the server (only the sources of flipper-server, flipper-server-core and other flipper packages are bundled, node-deps are left as is).
To achieve this, since metro doesn't have support for 'external' packages like any arbitrarily other bundler, we recycle the electronRequire work around that is used in the desktop app as well
Reviewed By: aigoncharov
Differential Revision: D32949677
fbshipit-source-id: 00d326bb17b68aece6fb43af98d0def13b335e74
Summary:
Sorry for long diff! I can try to split it if necessary, but many changes here are 1-1 replacements / renames.
**Preambule**
Currently we bundle default plugins into the Flipper main bundle. This helps us to reduce bundle size, because of plugin dependencies re-use. E.g. if multiple plugins use "lodash" when they are bundled together, only one copy of "lodash" added. When they are bundled separately, the same dependency might be added to each of them. However as we're not going to include most of plugins into Flipper distributive anymore and going to rely on Marketplace instead, this bundling doesn't provide significant size benefits anymore. In addition to that, bundling makes it impossible to differentiate whether thrown errors are originated from Flipper core or one of its plugins.
Why don't we remove plugin bundling at all? Because for "dev mode" it actually quite useful. It makes dev build start much faster and also enables using of Fast Refresh for plugin development (fast refresh won't work for plugins loaded from disk).
**Changes**
This diff introduces new option "no-bundled-plugins" for "yarn start" and "yarn build" commands. For now, by default, we will continue bundling default plugins into the Flipper main bundle, but if this option provided then we will build each default plugin separately and include their packages into the Flipper distributive as "pre-installed" to be able to load them from disk even without access to Marketplace.
For "yarn start", we're adding symlinks to plugin folders in "static/defaultPlugins" and then they are loaded by Flipper. For "yarn build" we are dereferencing these symlinks to include physical files of plugins into folder "defaultPlugins" of the produced distributive. Folder "defaultPlugins" is excluded from asar, because loading of plugins from asar archive might introduce some unexpected issues depending on their implementation.
Reviewed By: mweststrate
Differential Revision: D28431838
fbshipit-source-id: f7757e9f5ba9183ed918d70252de3ce0e823177d
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/2172
New script which runs "tsc" for all plugins, receives list of errors and then checks which plugins are affected. It works for shared libs too, e.g. if there is an error in a shared library, then all plugins dependant on it will be counted as affected. For convenience, script saves list of errors affecting each plugin to "tsc-errors.log" in plugin folder.
This script will be used for automatic type-checking plugins against current "stable" and "insiders" versions of Flipper.
An alternative to this implementation would be to simply run "tsc" for each plugin individually, but such implementation takes a lot of time (5+ sec per plugin) and so cannot be effectively used on diffs.
Reviewed By: mweststrate
Differential Revision: D27499765
fbshipit-source-id: fcbbfc94a13e6c7c5beff0c889a929f84c41b2dd
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
Summary:
allow-large-files
This makes the Ant.design component library available to Flipper
The CSS setup is unconventional, in the sense that the normal way to do this is to use a webpack loader to dynamically load the right less files, and a babel transform to automatically import the style sheets.
Since we use Metro, which is not very suitable for transforming non-JS(like) files, I figured that the simplest thing is to pre-compile the entire less theme. Which should be fine since we shouldn't be changing the less files very often, and since we don't ship a website, it is probably not too bad to have the full ANT theme for now in there, even though we don't use all components. It is 600 K of css. In the next diff the CSS is loaded conditionally, only if Sandy is enabled.
If the CSS turns out to be too big we can optimise this later to only import CSS for components we use by doing some Metro magic, but it doesn't seem to be trivial (that is, I couldn't get in to work in < 2 hours).
Reviewed By: cekkaewnumchai
Differential Revision: D23625855
fbshipit-source-id: 3ba810b2221dc0c7b719f66310e590c7748cf239
Summary:
I want to track that data continuously.
HTML is useful to investigate, lcov got loads of external tools that
support it and JSON is quite useful to parse and write to a DB.
Pull Request resolved: https://github.com/facebook/flipper/pull/1051
Test Plan:
```
yarn test --coverage
open coverage/index.html
```
Reviewed By: jknoxville
Differential Revision: D21228144
Pulled By: passy
fbshipit-source-id: dc6d853c84c21e941614cf7e5da0fc4fe7174564
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/998
After this diff all the default plugins (which are distributed with Flipper) will be included into the main app bundle instead of bundling each of them separately and then loading from file system. This is done by auto-generating plugins index in build-time and importing it from Flipper app bundle, so Metro can follow these imports and bundle all the plugins to the app bundle.
This provides several benefits:
1) reduced Flipper bundle size (~10% reduction of zipped Flipper archive), because Metro bundles each of re-used dependencies only once instead of bundling them for each plugin where such dependency used.
2) Faster Flipper startup because of reduced bundle and the fact that we don't need to load each plugin bundle from disk - just need to load the single bundle where everything is already included.
3) Metro dev server for plugins works in the same way as for Flipper app itself, e.g. simple refresh automatically recompiles bundled plugins too if there are changes. This also potentially should allow us to enable "fast refresh" for quicker iterations while developing plugins.
4) Faster build ("yarn build --mac" is 2 times faster on my machine after this change)
Potential downsides:
1) Currently all the plugins are identically loaded from disk. After this change some of plugins will be bundled, and some of them (third-party) will be loaded from disk.
2) In future when it will be possible to publish new versions of default plugins separately, installing new version of such plugin (e.g. with some urgent fix) will mean the "default" pre-built version will still be bundled (we cannot "unbundle" it :)), but we'll skip it and instead load new version from disk.
Changelog: Internals: include default plugins into the main bundle instead producing separate bundles for them.
Reviewed By: passy
Differential Revision: D20864002
fbshipit-source-id: 2968f3b786cdd1767d6223996090143d03894b92
Summary: Added tsconfig.base.json and extend other tsconfigs from it.
Reviewed By: passy
Differential Revision: D20594653
fbshipit-source-id: 28dd80262613e78a7c4ce25fa31f251537ec2b06
