Summary:
About to release React Native 0.72.1. This version of React Native has to depend on SocketRocket 0.7.0, released yesterday.
Cocoapods is failing to install dependencies with the following error:
```
In snapshot (Podfile.lock):
SocketRocket (= 0.7.0)
In Podfile:
FlipperKit/FlipperKitReactPlugin (= 0.182.0) was resolved to 0.182.0, which depends on
FlipperKit/Core (= 0.182.0) was resolved to 0.182.0, which depends on
SocketRocket (~> 0.6.0)
React-Core/RCTWebSocket (from `../react-native/`) was resolved to 1000.0.0, which depends on
SocketRocket (= 0.7.0)
React-CoreModules (from `../react-native/React/CoreModules`) was resolved to 1000.0.0, which depends on
SocketRocket
```
By bumping the SocketRocket dependencies and publishing a new version of FlipperKit, we would be able to release React Native.
Reviewed By: passy, cipolleschi
Differential Revision: D47125059
fbshipit-source-id: d0797880c502c14db9f0261c3e8abf2652e7bba2
Summary: This change reverts a revert. The change was reverted for 'unrelated' issues addressed on this diff dependencies.
Reviewed By: passy
Differential Revision: D30696113
fbshipit-source-id: 8591d6ea79999597024c316e9927a346979e5219
Summary: Revert D30371791 (cac09d14aa) to address undefined symbols for a few sandcastle jobs
Reviewed By: fabiomassimo
Differential Revision: D30606610
fbshipit-source-id: 24a5c08bcf5456a96469650a4207b05970399181
Summary:
Contains the implementation of FlipperWebSocket with any necessary changes to use it but without switching it on.
About SocketRocket and Cocoapods
A decision had to be made about whether to define different sub-specs, one for RSocket and another for SocketRocket.
I've opted to keep the podspec as is because:
- Keeps pod consumption as is.
- Makes easier to switch implementations using GK.
- There's no intention to keep RSocket going into the future. So, there's no point in creating a sub-spec only to remove it in the future.
- SocketRocket is a relatively small library so is not contributing to a significant increase in binary size.
If, as reviewer, you consider a subspec makes more sense, then feel free to reach out to discuss.
Reviewed By: fabiomassimo
Differential Revision: D30371791
fbshipit-source-id: 225c5b1de76aff1a6e36640a41765b963aaa2796
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 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:
This diff repaces the faulty sonarkit.xcodeproj with the current one. I think ship it synced the xcodeproj which was generated by buck.
Closes https://github.com/facebook/Sonar/pull/96
Reviewed By: emilsjolander
Differential Revision: D8538609
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 9eb049a9770c40b652f999ace9b82207e3a395e5
