Summary: Moved all types related to plugin descriptions from plugin-lib (which handles downloads and such) to flipper-common. The goal of that is to remove all plugin-lib usage from ui-core to server-core, so that the UI itself doesn't do any file operations anymore related to plugins. That will be done in next diffs, this just moves types but no code.
Reviewed By: nikoant, aigoncharov
Differential Revision: D32665064
fbshipit-source-id: 86d908e7264569b0229b09290a891171876c8e00
Summary:
`flipper-pkg init` would always introduce `flipper-plugin` peer with version `latest`. Since that can never be checked against the current flipper version, it always generated a warning. Updated the init process to take the version the plugin was generated with as base version instead.
Note that in the test the version will always display as 0.0.0, will double check after release that the proper version will show up when running from npx, but don't see a reason why not (famous last words)
Reviewed By: nikoant, priteshrnandgaonkar
Differential Revision: D28992531
fbshipit-source-id: c32aad1650f575f790c2e04d089104b7a616d26f
Summary:
Few improvements for "build-plugin" task which together with Sandcastle command changes (D26872427) helps to build all plugins in CI ~30% faster if most of them has not changed (which is usually the case):
1) compute package checksum in the same script to not call additional yarn scripts for each plugin
2) avoid packaging plugin if it's checksum has not changed since last release
Reviewed By: mweststrate
Differential Revision: D26872253
fbshipit-source-id: 968102d32a1550ea7503f1169f0ef2863296383f
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:
I've re-designed interfaces describing plugins as I found that mental overhead working with them became too expensive because of slightly flawed design. However this cascaded changes in many files so you can see how extensively these interfaces used in our codebase.
Before this change we had one interface PluginDetails which described three different entities: 1) plugins installed on the disk 2) plugins bundled into Flipper 3) plugins available on Marketplace. It's hard to use this "general" PluginDetails interface because of this as you always need to think about all three use cases everywhere.
After this change we have 3 separate interfaces: InstalledPluginDetails, BundledPluginDetails and DownloadablePluginDetails and things became much type-safer now.
Reviewed By: mweststrate
Differential Revision: D25530383
fbshipit-source-id: b93593916a980c04e36dc6ffa168797645a0ff9c
Summary: Extracted plugin marketplace API to a separate file and updated it to load full plugin manifests.
Reviewed By: passy
Differential Revision: D25181759
fbshipit-source-id: a63f9ce16249ccc170df148cef5c209fdc6d4d6d
Summary: Changelog: Added command `flipper-pkg checksum` for computing the total checksum of all the files included into plugin package.
Reviewed By: passy
Differential Revision: D22255125
fbshipit-source-id: a4f91370b4ab16ea4ce4a60e29f9d20fdd5f4331
Summary:
When running `flipper-pkg init path/plugin`, this allows to skip the `Do you wanna add this path to watching in Flipper config?`, if the path is direct first level subdirectory of any added path from Flipper `pluginPaths: []`
## Changelog
- Improve matching for watched pluginPaths when initialising new plugin
Pull Request resolved: https://github.com/facebook/flipper/pull/1269
Test Plan:
1. Create folder: `~/flipper-plugins`
2. Add this folder to Flipper config `pluginPaths: ['~/flipper-plugins']`
3. Create new subfolder `test-plugin`
4. Run `flipper-pkg init test-plugin`
5. It should not ask to add this folder to pluginPaths
To verify it only works for first level subdirectory, create another folder: `/deep/test-plugin2` and re-run steps with it.
This should also keep working if we specify exactly the path for the plugin itself.
Reviewed By: mweststrate
Differential Revision: D22065630
Pulled By: jknoxville
fbshipit-source-id: 9ef8d364e3815033b63579e37a6f2d19515ca902
Summary: Freshly init-ed plugins are not picked up by Flipper if they are not on the search path. This diff checks if the current dir is on the search path, and, if not, suggests to add it.
Reviewed By: jknoxville
Differential Revision: D21619632
fbshipit-source-id: b1dbe2695dbee9ce537999dc83e36f969ba4b747
Summary:
Created a test that snapshots the generated files, so that we can capture accidental regressions when generating files.
Also made the package id to package name a bit more robust
Reviewed By: jknoxville
Differential Revision: D21619633
fbshipit-source-id: 88ffb127e050d840df9ccd4b15ba29a71f341975
Summary:
Although there are tools that do this for you (create-react-app, react-native), and other that assume you are already in the created directory before you invoke the command (typescript, git), creating the directory by the tool has a few benefits:
1. less risk of making an accidental mess when people assume they don't need to create the dir first (I definitely ended up with a node_modules in the wrong directory)
1. it provide a naive way of detecting plugin name conflicts early (at least for plugins you create yourself)
1. in the next diff I'll add a pkg suggestion to add the current directory to the search path for flipper plugins. In the current setup, that would require needing to suggest to add the parent directory, which somehow feels less logical
2. makes sure that the directory name follows npm conventions: the package.json name should match the current directory name (not super important, but e.g VSCode will show warnings otherwise)
Reviewed By: jknoxville
Differential Revision: D21619631
fbshipit-source-id: 6d027ad18f14659e0347a66cacf056eacbc65680
Summary:
Added a watch mode to the bundle command of flipper plugins. This makes it easy to test develop plugins locally, even when you are using a production build of flipper, which lowers the barrier of developing / fixing plugins.
opted for `fs.watch` over watchman to avoid some overengineering:
1. pkg / pkg-lib don't have the watchman utilities that would be needed for this. I wasn't sure if I could move those over from `static` without breaking the bootstrapping process
2. watchman is often a nuisance on non FB machines that aren't set up for it. fs.watch in contrast doesn't have any further dependencies or setup requirements, and is much more likely to work ootb.
3. since we watch only the `src` folder we don't really need the watchman optimizations. (so for a package.json change people would have to restart, but I don't think that is much of a problem).
Reviewed By: jknoxville
Differential Revision: D21523814
fbshipit-source-id: b1de72b7d01c6fc50cb8ce5709f54f8019eb89e4
Summary:
Searched for broken link patterns inside the app itself. I think I found them all but it's not certain.
Patterns searched for and replaced:
```
.html
getting-started/)
getting-started)
getting-started"
```
and also searched the repo for regex `\]\(.*)` and checked them by eye.
Reviewed By: passy
Differential Revision: D21306944
fbshipit-source-id: a2e09b0fd8677f5f26e5cc4a06805b474247f7e6
Summary: "migrate" command for easy migration of existing Flipper plugins to the specification version 2.
Reviewed By: passy
Differential Revision: D21253913
fbshipit-source-id: 9edb170fbaa10e9c3f670d5d68e69f4f6106c151
Summary:
Implemented json schema for flipper plugin package.json and used it for validation in "flipper-pkg lint" command.
Nice thing about json schema is that it not only allows to validate json, but also can be referenced using "$schema" property in json so IDEs like VSCode can find it and use for code completion, validation and to show properties documentation. I'm going to deploy the schema as a part of documentation website so it can be referenced as https://fbflipper.com/schemas/plugin-package/v2.json.
Also the "$schema" field can be used instead of "specVersion" to determine the specification according to which the plugin is defined. E.g., if specification version 3 would be created, it will be described in schema https://fbflipper.com/schemas/plugin-package/v3.json, etc.
Reviewed By: passy
Differential Revision: D21228294
fbshipit-source-id: f21351e584ef936a7d6b314436448489691f83a6
Summary:
Command which transpiles and bundles plugin code.
It is supposed to be used in "prepack" script for all open-sourced plugin packages to bundle them before publishing like this:
```
{
"devDependencies": {
"flipper-pkg": "latest"
},
"scripts": {
"prepack": "flipper-pkg bundle"
}
}
```
Also made directory parameter of other command "pack" optional so it also can be called from plugin directory simply by `flipper-pkg pack`.
Changelog: "flipper-pkg bundle" command for bundling plugins before publishing.
Reviewed By: mweststrate
Differential Revision: D21129691
fbshipit-source-id: 8f97bc950c28cf9ad8b0117c0e1d811ed1b988eb
Summary: Renamed command "bundle" to "pack" because the latter name better describe what the command does. Also I'm going to add another command which will only bundle the plugin code and it will be called "bundle" (see the next diff in this stack)
Reviewed By: mweststrate
Differential Revision: D21129690
fbshipit-source-id: 2dde30501c3776d6796c27c68d49948d1f84f822
Summary:
Added versioning for plugin format.
The first version is where "main" points to source code entry and plugins are bundled by Flipper in run-time on loading them.
The second version is where "main" points to the already existing bundle and Flipper just loads it without bundling. The plugins of version 2 must be bundled using "flipper-pkg" tool before publishing.
Changelog: Support new packaging format for plugins.
Reviewed By: mweststrate
Differential Revision: D21074173
fbshipit-source-id: 7b70250e48e5bd5d359c96149fb5b14e67783c4d
Summary: "flipper-pkg" added ~2MB to Flipper disttributive size, because of heavy dependencies which are only required for CLI functionality. See size warning in diff D21068373 in this stack where I added pkg as dependency to flipper. Here I'm splitting it into library and CLI packages, so Flipper app will only reference the library.
Reviewed By: passy
Differential Revision: D21087336
fbshipit-source-id: d9d62f1e75a835d1c0fa78ff1addb0d9a761a9c7
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/872
Move all the JS code related to desktop app to "desktop" subfolder.
The structure of "desktop" folder:
- `src` - JS code of Flipper desktop app executing in Electron Renderer (Chrome) process. This folder also contains all the Flipper plugins in subfolder "src/plugins".
- `static` - JS code of Flipper desktop app bootstrapping executing in Electron Main (Node.js) process
- `pkg` - Flipper packaging lib and CLI tool
- `doctor` - Flipper diagnostics lib and CLI tool
- `scripts` - Build scripts for Flipper desktop app
- `headless` - Headless version of Flipper app
- `headless-tests` - Integration tests running agains Flipper headless version
Reviewed By: passy
Differential Revision: D20249304
fbshipit-source-id: 9a51c63b51b92b758a02fc8ebf7d3d116770efe9
