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
