[podspec] Fixes current CI failures and allows tree shaking of native dev support code. #12602
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The podspec still depends on the accompanying NPM package’s package.json file, so there’s not really any point in hardcoding the version.
* This allows more tree shaking. * Removes RCTWebSocket dependency from Core in development mode.
facebook-github-bot
added
CLA Signed
alloy
commented
Feb 27, 2017
| @@ -116,7 +119,7 @@ - (void)start | |||
| sourceCode = source; | |||
| dispatch_group_leave(initModulesAndLoadSource); | |||
| } onProgress:^(RCTLoadingProgress *progressData) { | |||
| #ifdef RCT_DEV | |||
| #if RCT_DEV && __has_include("RCTDevLoadingView.h") | |||
There was a problem hiding this comment.
This used to check if the macro is defined, which it always is, so I made it consistent with the rest of the code base (which is to check its value).
alloy
commented
Feb 27, 2017
| @@ -18,13 +18,9 @@ | |||
| #import "JSCSamplingProfiler.h" | |||
| #import "RCTBridge+Private.h" | |||
| #import "RCTBridgeModule.h" | |||
| #import "RCTDevMenu.h" | |||
There was a problem hiding this comment.
This import wasn’t actually required, so I left it out.
alloy
commented
Feb 27, 2017
facebook-github-bot
added
GH Review: accepted
Import Started
|
@facebook-github-bot shipit |
|
@ericvicenti has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
GaborWnuk
pushed a commit
to GaborWnuk/react-native
that referenced
this pull request
Feb 28, 2017
…rt code. Summary: * The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability. It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development. * I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec. Closes facebook#12602 Differential Revision: D4621021 Pulled By: ericvicenti fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
dudeinthemirror
pushed a commit
to dudeinthemirror/react-native
that referenced
this pull request
Mar 1, 2017
…rt code. Summary: * The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability. It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development. * I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec. Closes facebook#12602 Differential Revision: D4621021 Pulled By: ericvicenti fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
dudeinthemirror
pushed a commit
to dudeinthemirror/react-native
that referenced
this pull request
Mar 1, 2017
…rt code. Summary: * The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability. It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development. * I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec. Closes facebook#12602 Differential Revision: D4621021 Pulled By: ericvicenti fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
ghost
mentioned this pull request
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The dev support code moved into a
DevSupportsubspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability.It also improves the weird situation where you had to specify the
RCTWebSocketsubspec if you wanted to be able to use the packager client during development.I removed hardcoding the release version in the podspec on release, because the podspec still relies on
package.jsonwhen evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec.