Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add My IP to showcase #5867

Closed
wants to merge 8 commits into from
Closed

Add My IP to showcase #5867

wants to merge 8 commits into from

Conversation

joshbuchea
Copy link
Contributor

No description provided.

@facebook-github-bot
Copy link
Contributor

By analyzing the blame information on this pull request, we identified @brentvatne, @chirag04 and @kirkness to be potential reviewers.

@facebook-github-bot
Copy link
Contributor

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks!

@facebook-github-bot
Copy link
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Feb 11, 2016
@facebook-github-bot
Copy link
Contributor

@joshbuchea updated the pull request.

@skevy
Copy link
Contributor

skevy commented Feb 11, 2016

@facebook-github-bot shipit

@facebook-github-bot
Copy link
Contributor

@joshbuchea updated the pull request.

@skevy
Copy link
Contributor

skevy commented Feb 12, 2016

@facebook-github-bot shipit

@facebook-github-bot
Copy link
Contributor

Thanks for importing. If you are an FB employee go to https://our.intern.facebook.com/intern/opensource/github/pull_request/1682154482052528/int_phab to review.

@joshbuchea
Copy link
Contributor Author

Hmm what did I do wrong?

@joshbuchea
Copy link
Contributor Author

@skevy sorry to trouble you, but the import failed, and I'm not sure why. Any chance you could enlighten me?

@skevy
Copy link
Contributor

skevy commented Feb 13, 2016

@joshbuchea can you rebase this PR? After you do that I'll try shipping it again

joshbuchea and others added 8 commits February 13, 2016 15:26
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on facebook/fbjs#95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.

This PR does several things:

1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes #5084

Reviewed By: bestander

Differential Revision: D2803288

Pulled By: davidaurelio

fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary:
As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on facebook/fbjs#95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm.

This PR does several things:

1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`.
2. Removes the modules that were previously being used in lieu of their `fbjs` eq
Closes #5084

Reviewed By: bestander

Differential Revision: D2803288

Pulled By: javache

fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Reviewed By: ivank

Differential Revision: D2921881

fb-gh-sync-id: bd35ada33c752877dd3f6274ed8d4b4b7c851b9a
shipit-source-id: bd35ada33c752877dd3f6274ed8d4b4b7c851b9a
Summary:
Copy of #5760 reverted merge.

We need to preserve history of docs changes on the webserver.
The goal is to allow users to browse outdated versions of docs.
To make things simple all websites will be released to https://facebook.github.io/react-native/releases/version/XX folder when there is a branch cut.

I switched from Travis CI to Cirle CI because it works faster and I am more familiar with it.

How it works:

1. If code is pushed to `master` branch then CI will build a fresh version of docs and put it in https://github.com/facebook/react-native/tree/gh-pages/releases/next folder.
Github will serve this website from https://facebook.github.io/react-native/releases/version/next URL.
All relative URLs will work within that website

2. If code is pushed to `0.20-stable` branch then CI will build a fresh version of docs and put it in https://github.com/facebook/react-native/tree/gh-pages/releases/0.20 folder.
Github will serve this website from https://facebook.github.io/react-native/releases/v
Closes #5873

Reviewed By: svcscm

Differential Revision: D2926901

Pulled By: androidtrunkagent

fb-gh-sync-id: 16aea430bac815933d9c603f03921cc6353906f1
shipit-source-id: 16aea430bac815933d9c603f03921cc6353906f1
Summary:
public
#4935 changed the window dimensions for android by replacing them with the actual screen dimensions. This changes the window dimensions back to their original values and adds `Dimensions.get('screen')` for the actual screen dimensions of the device.

Reviewed By: astreet

Differential Revision: D2921584

fb-gh-sync-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
shipit-source-id: 5d2677029c71d50691691dc651a11e9c8b115e8f
Reviewed By: mkonicek

Differential Revision: D2927075

fb-gh-sync-id: b3a7d1541d11d7d9ebf01f72dac48847750968f8
shipit-source-id: b3a7d1541d11d7d9ebf01f72dac48847750968f8
Summary:
Just testing the shipit bot
Closes #5843

Reviewed By: svcscm

Differential Revision: D2917790

Pulled By: mkonicek

fb-gh-sync-id: f73a9bf3aee82d1074f68d650f2bf30ac720a66d
shipit-source-id: f73a9bf3aee82d1074f68d650f2bf30ac720a66d
@facebook-github-bot
Copy link
Contributor

@joshbuchea updated the pull request.

@joshbuchea
Copy link
Contributor Author

@skevy First time rebasing a PR. Hopefully I did it correctly.

@skevy
Copy link
Contributor

skevy commented Feb 14, 2016

Nope. :(

You have two options now:

  1. You can close this PR and open a new one with your change (if you do this, feel free to tag me in it and I'll get it merged).
  2. You can scrap this branch, re-create it with your changes, and force-push it back to your repo.

I'd recommend number 1 for simplicity's sake.

For future reference...

Adam's guide to GitHub (you may have done some of these steps already...but just for reference):

  1. Fork RN to your Github.

  2. Pull down your fork and create a branch.

    git clone [email protected]:[your username]/react-native.git
    git remote add fb-upstream [email protected]:facebook/react-native.git
    git checkout -b my-pr-branch-name # this creates a new branch, based off of master
  3. Make your changes and commit them.

  4. Rebase your changes on to fb-upstream/master:

    git checkout my-pr-branch-name # make sure you're on your branch
    git fetch fb-upstream # pull down the latest changes from upstream, but don't merge them
    git rebase fb-upstream/master # rebase your changes onto FB master

    If there are any conflicts...fix them and follow the instructions.

  5. Push to your remote branch:

    git push origin my-pr-branch-name

You can repeat these steps for every PR you ever make, and you can repeat steps 3, 4, and 5 to continue making changes and keep your PR up-to-date with upstream.

Note that on step 5 -- you'll most likely need to force push (use the -f flag), as the commit history will have changed when you rebase. Do this with caution.

@joshbuchea
Copy link
Contributor Author

Ha figures. :)

I'll take your advice and go with option #1. Thank you very much for the detailed feedback @skevy. It's very helpful to a rebasing noob like myself.

@joshbuchea joshbuchea closed this Feb 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants