Summary:
The PWA manifest is very unlikely to change at the same frequency that tokens get generated and injected here.
Add it to .gitignore so that these changes are, well, ignored.
Reviewed By: antonk52
Differential Revision: D45950055
fbshipit-source-id: bd082f3bf005c7746c7dd3682b4ebde039633398
Summary:
Bit annoying if everytime we run it we have to manually delete/discard file.
So, add to gitignore.
Reviewed By: LukeDefeo, passy
Differential Revision: D45688164
fbshipit-source-id: 6ae2b570f571a3d44b0c75bb3d614887e4943e5b
Summary:
Added concept of a tree observer which is responsible for listening to the changes for a portion of the UI tree. This structure nests so Tree observers can hold child tree observers which emit events on a different cadence. This structure should allow us to incorporate different UI frameworks down the road as well as native android views.
We push the tree updates from the tree observers onto a channel and setup a coroutine to consume this channel, serialize and send down the wire.
Reviewed By: lblasa
Differential Revision: D39276681
fbshipit-source-id: a4bc23b3578a8a10b57dd11fe88b273e1ce09ad8
Summary: `cargo vendor` to update the offline mirror we have. Will change our UTD setup next to verify it's update and eliminate the need to run with fwdproxy.
Reviewed By: lblasa
Differential Revision: D37247737
fbshipit-source-id: bb1d0f5b60f047694f6e4bb12113e1581016f160
Summary:
This diff changes the way on how plugin documentation is produced. Instead of keeping plugin documentation together with other docs, we will now keep it together with plugin code. There are multiple advantages of such solution:
1. We are generating docs for every plugin in a standartised way so all of them looks similar. We can also use plugin metadata for generation as well (e.g. take title, icon, oncall name etc from package.json).
2. Standartised plugin docs make it possible to build docs both for websites (public and internal) and for embedding into Flipper.
3. It will hopefully incentivise authors to write docs as they will be a part of plugin "package".
4. We can scaffold documentation template using scarf to further incentivise filling it.
Reviewed By: jknoxville
Differential Revision: D29378053
fbshipit-source-id: 66ea48dc9ba225fabfb256ae6a10f8c81eef6f5f
Summary:
New script which can download "stable" or "insider" sources and link current version of plugins there, so we could check whether they are backward compatible.
It extracts downloaded sources to "desktop-branch-stable" / "desktop-branch-insiders" and symlinks current plugins there as "plugins-current" subfolder. It makes it even possible to open these folders in VSCode and fix highlighted typing problems if author want to fix compatibility with older versions of Flipper.
Reviewed By: mweststrate
Differential Revision: D27501743
fbshipit-source-id: 7dd76928ec4ac0c42191f67e0abd214b5bec1495
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: This diff commits Podile.lock, once this diff gets landed I will add a github action to automatically raise a PR with the updated Podfile.lock
Reviewed By: cekkaewnumchai
Differential Revision: D21348940
fbshipit-source-id: e3bcdb8699442aa8d3092d9517c332eeb9c02981
Summary:
Docusaurus 2 is quite a lot more powerful than docu 1 it turns out.
This should convert the website fully.
* [done] Go through migration guide https://v2.docusaurus.io/docs/migrating-from-v1-to-v2
* [done] Convert landing page html
* [done] Convert all images to img tags
* [done] Convert all .md files to .mdx
* [done] Make sure ui-doc generation and including still works
* [done] Scan every page visually for sanity check
* [done] Make sure footer still works
* [done] Make sure search still works
* [done] Change all links/ to links/index
* [done] Change all links.md to links
* [done] Add some custom css to make the navbar look like the old one and darken the footer.
Reviewed By: passy
Differential Revision: D21158717
fbshipit-source-id: 5f45b711b1b6fd5ece4c5c15c55635c7ebbfb568
Summary:
Original commit changeset: 41028c11da6c
I will use mitmproxy for offline support, but till then lets back out the diff and make our tests work for all cases
Reviewed By: passy
Differential Revision: D20514538
fbshipit-source-id: c081baba0a0c7189ae862a66b6116f26b1401177
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
Summary:
This diff adds the ability to run iOS tests without doing pod install in sandcastle. For this, the repo will already have the dependencies archived and checked into the repo. For this I have already added the script, `recreate_offline_mirrors` which takes the first argument, which is the sample app's name, in our case it will be `Sample` and `SampleSwift`. There is one more script `prepare_pods` which untars the dependencies and copies it into the Pods folders.
Reason we are moving away from using `pod install` is that internet is unreliable in sandcastle and there have been many instances that the job fails due to flaky internet.
Reviewed By: passy
Differential Revision: D20136440
fbshipit-source-id: 41028c11da6c66b484f36c7d1090ac7ffd847ec2
Summary:
As a first step I've configured bundling for the main process code using Metro. For now I haven't converted anything to ts, just made that possible.
The bundle is just produced into the "static" directory. To avoid too many changes I kept the "static" folder as it is, but probably non-static code should be moved from there.
Also installed modules from "node_modules" for the main process are not bundled to avoid potential issues with node native modules.
Reviewed By: mweststrate
Differential Revision: D19960982
fbshipit-source-id: efbd426254e2b37c913c5f5f75f042c50ccee2f3
Summary: Added docs on how to write React-Native JavaScript based plugins
Reviewed By: passy
Differential Revision: D19344803
fbshipit-source-id: ad1ea66f1031760729fdaea8a7e6c1ef5dcd5439
Summary:
Seems to be a new thing from the Android Build system
and it's quite annoying.
Reviewed By: jknoxville
Differential Revision: D17163339
fbshipit-source-id: 938264d301e7546a4a6e3276e91184ab5498a833
Summary: These get generated by VSCode if you have java installed and open the flipper project.
Reviewed By: danielbuechele
Differential Revision: D16763411
fbshipit-source-id: 40c7d943ee2ee32cf70f9aea080f5e44716e5651
Summary:
VSCode generates a bunch of java output when you open the project with it.
This correctly ignores those files.
Reviewed By: passy
Differential Revision: D16687798
fbshipit-source-id: bbb2b2f89c987305109b4c02d07a6b6e9a3a7301
Summary: It's not necessary for the sample app itself, and causes a lot of conflict trouble.
Reviewed By: passy
Differential Revision: D9971997
fbshipit-source-id: 99b822c7a317487d841b939bf99e0dedcc172d37
Summary:
This PR adds support for using SonarKit clients in Swift apps. Fixes#13, fixes#87
1. Swift can't import Obj-C modules which have C++ headers. For this reason, we use SonarKit as an Obj-C++ wrapper around Sonar, which is written in C++. Due to search path misconfiguration, trying to import SonarKit into a Swift project would import `xplat/Sonar/SonarPlugin.h` instead of `iOS/SonarKit/SonarPlugin.h`, which caused `file not found` errors for C++ stdlib imports like #28 because new projects don't have their search paths set up correctly.
2. The network and layout plugins have C++ definitions (struct methods, classes) in some of their headers. This causes the compiler to get confused for Swift projects, because it only supports importing Objective-C files in umbrella headers, meaning that the `SonarKit` won't build.
1. I updated the `HEADER_SEARCH_PATHS` of SonarKit.podspec's build configuration to include `${PODS_ROOT}/Headers/Private/SonarKit/**` first, which alleviates the search path issue. The Obj-C `Sample` project seems to have worked around this by including a hardcoded `${PODS_ROOT}/SonarKit/**` search path in the pbxproj, which is why Sample works but new projects (like those referenced in #28) don't. I removed this since it's no longer necessary.
2. I added a `SampleSwift` app to demonstrate using Sonar with a Swift project.
3. Because the Podfiles for `Sample` and `SampleSwift` referenced podspecs using `:podspec` instead of a concrete version, Cocoapods wouldn't copy local header files (instead, it downloads them from the source). To enable local development of these sample apps using `:path`, I added a symlink to SonarKit.podspec in the root of the directory.
4. I changed SonarKit.podspec to use a tag-based `source`, since v0.0.1 pulls from the master branch of this repo.
The layout and network plugins still don't work with Swift - in order to fix this, we'll need to work on extracting the C++ out of their headers and writing Obj-C++ wrappers for them. I decided to push this off to a later PR since this one is quite large already.
This means that we need to be able to `import SonarKit` without importing all the network/layout plugin headers. In order to make this work, I made "SonarKit/Core" the spec's `default_subspecs`.
priteshrnandgaonkar, let me know if you have any thoughts on this implementation. You can verify that the SampleSwift app works by checking out this branch, `pod install`ing in the SampleSwift directory, and building it :)
Pull Request resolved: https://github.com/facebook/Sonar/pull/106
Reviewed By: jknoxville
Differential Revision: D8890010
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 449305bcc5cbeb5787c23f51b1ecb80a5cbdad32
Summary:
This moves the native setup to a separate gradle file and unpacks everything outside the build folder. That way we don't throw everything away on every incremental build.
This is an intermediate step to get to a more declarative setup like Fresco has it and get rid of the individual hacks we have for every download.
Pull Request resolved: https://github.com/facebook/Sonar/pull/154
Reviewed By: jknoxville
Differential Revision: D8833812
Pulled By: passy
fbshipit-source-id: 2424c9d6e22e6092c04af344e06939b4a6aba041
Summary:
This PR brings us one step closer for publishing SonarKit.podspec to the public Cocoapods master repository. This solves [#93](https://github.com/facebook/Sonar/issues/93).
- [X] `SonarKit.podspec` now lints by passing the `--sources` flag and the `--use-libraries` flag. `pod spec lint SonarKit.podspec --sources=https://github.com/facebook/Sonar,master --allow-warnings --use-libraries` Same for `pod repo push`.
- [X] `SonarKit.podspec` is now also published to the CocoaPods Private repo. What does this mean? It means that we no longer need to manually define all of `SonarKit` dependencies in the Podfile. It only takes `SonarKit` consumers to add this line `source 'https://github.com/facebook/Sonar.git'` on top of any Podfile, and `SonarKit` will be installed by just defining it with `pod SonarKit`.
- [X] We are publishing a Cocoapods Private Repo in the meantime we don't have all of our dependencies updated and published to the CocoaPods master repo. The CocoaPods Private Repo contains updated dependency podspecs that will need to be published to the CocoaPods master repo in the near future. That will be the next action item in order to have SonarKit.podspec published as well.
- [X] Sample App Podfile has been refactored, much simpler and cleaner.
- [X] SonarKit Framework project now pulls its dependencies from the cocoapods master repository and the temporary private repository instead of the local podspecs. I am able to compile the SonarKit framework project now, before I was unable to.
- [X] Local third party podspec dependencies have been removed.
emilsjolander priteshrnandgaonkar noahsark769 feel free to contribute or expose any concerns.
Closes https://github.com/facebook/Sonar/pull/107
Reviewed By: danielbuechele
Differential Revision: D8694271
Pulled By: priteshrnandgaonkar
fbshipit-source-id: dcccf70d917cad1e27606a29c0b921883bf9a76f
Summary:
No need to include this in commits.
Closes https://github.com/facebook/Sonar/pull/54
Differential Revision: D8466428
Pulled By: xiphirx
fbshipit-source-id: f24c4afe30dd74a17dbf42535ba92e7467c9e33a
