Closed grabbou closed 6 years ago
Before we reach 0.57.0 we need to be sure this is fixed/closed: https://github.com/facebook/react-native/issues/20327
During RC phase should be enough to change the preset dep
- "presets": [ "react-native" ],
+ "presets": [ "metro-react-native-babel-preset" ],
But yeah we need to ensure the transition.
Will this issue be resolved by 0.57: https://github.com/facebook/react-native/issues/19953
When is 0.57 due for release? It has been frustrating not being able to use react native on Windows.
@kelset I believe you need to set module:metro-react-native-babel-preset
if the module name isn't prefixed with "babel-preset".
Also preferably this commit should be cherry picked in to the next release, it's one of the few issues that we're having to maintain a fork for.
Hey thanks for the feedback - we still haven't released the first rc because we had some issues testing RNTester, so we'll basically sync the 0.57 branch with master asap so you'll also get that fix (I want it too 😅).
Is there any chance of this commit entering version 0.57?
@rafaellincoln we are cutting the first RC of 0.57 today (unless during our testing something weird happens) and we'll basically synch the branch with master first, so you'd be able to see that commit in it 💪
Update on 0.57 please? I'm not seeing any RC on https://github.com/facebook/react-native/releases
While testing the branch we got stuck on this https://github.com/facebook/react-native/issues/20567
so until we resolve it we won't release.
In the meantime you can find a draft of the changelog for the new version in the dedicated branch - it's a WIP but if you want to have a quick view of what is going to happen there you can read it.
Quick update, we managed - with the help of a few amazing devs of this community - to finally get to a stage where we are feeling ok with releasing the first RC.
Currently CI is blocked by an invalid npm token, but it's being taken care of so expect 0.57-rc0 to be on npm in the next 12/24 hours.
While we are waiting for the npm
token to be released, there's work already happening on getting the docs in place (thanks to @turnrye).
We are looking for a period of ~2 weeks before we promote RC to stable. That should give us enough time to make sure it works without any major regressions and get us back into the monthly release cycle.
Note: The release cycle is being currently discussed here
React Native 0.57.0-rc.0 is out https://www.npmjs.com/package/react-native/v/0.57.0-rc.0. The docs are going to be published in a while I believe.
Can't go further than react-native-git-upgrade 0.57.0-rc.0
since that's breaking for me.
Good old react-native upgrade
is also broken.
A few issues and PRs we should try to have merged (and cherry picked) for 0.57.0:
Is react-native published to nexus?
Because there are issues with many native libraries, with dependencies like compile 'com.facebook.react:react-native:+'
- where Android Studio tries to download 0.20.1 and compile against that.
Update:
Many native modules reference maven { url "$projectDir/../node_modules/react-native/android" }
, but react-native/android
does not exist.
Once it's merged, can we cherry-pick https://github.com/facebook/react-native/pull/20705 onto 0.57-stable and cut another RC for react-native-windows
and react-native-dom
. +@vincentriemer
Will this issue #19859 (testing) be fixed in version 0.57? It feels weird for a lot of new people that testing is broken out of the box.
Yes, @janhesters, this should be fixed. I already commented on that issue. Thanks for rising that - this is exactly what this issue is for.
@danielgindi, please raise your issue in RN repository itself. The RN comes always from node_modules
and we never publish the Android version to any external dependency center (including Maven etc.). I believe there might be some historical versions published there, which gives you an error about the wrong version. Try installing node modules again.
@fungilation there's ongoing discussion about whether to rewrite/drop react-native-git-upgrade
entirely due to its brittleness with new upgrades. Are you able to provide your feedback about it, preferably via email? (it's on my profile) We could start a proposal to create a better, new, version of it. If you feel like having enough free time, I could help you get it up and running.
@grabbou Awesome news! Thank you very much.
Update on my previous comment:
To answer @janhesters - if you've read my comment at the bottom in that issue, it explains how it's not a react-native issue per se. That said we may consider "removing" jest from the init template so that we can avoid this:
It feels weird for a lot of new people that testing is broken out of the box.
@kelset - I commented on facebook/react-native#20706. That comment does not depend on the change to metro
. Metro still accepts the option for --reset-cache
, the change to metro
only affects the internal handling of that flag and ensures it's passed down to jest-haste-map
Edit: Also - https://github.com/facebook/react-native/commit/c5297c75cb6da58a241c8f91b0d2fefbc5835a46 is not blocked on metro either, so that can be cherry-picked ASAP so we can release an RC for react-native-windows
targeting 0.57 RC.1.
@grabbou I'm emailing you. But I'll say here that react-native-git-upgrade
has been reliably upgrading every version for me since about 0.50 or earlier. And no doubt it's better than react-native upgrade
with its 3 way merging of template files, instead of manual diffing. I'm all for a better version of react-native-git-upgrade
.
@kelset Yup I've read your comment and it helped me tremendously! It's a well working fix, thank you very much for that.
Why not just add that fix to the stable version of React Native? In my opinion removing jest from react-native init
template would be a bad move, because having Jest shipped with React Native encourages great programming!
I always loved for example how Django also ships with testing files and has a explicit chapter about testing in it's docs.
When I first picked up React Native I was excited to see that other frameworks also animate the user to write tests. It's an amazing privilege for new programmers, when they get lead by more experienced programmers to use best practices and write long-term stable code 🔥🤓
WKWebView
cherry-pick requestA stack of commits landed on master a few days ago, which bring support for WKWebView
-backed WebView
s in React Native. With the deprecation of UIWebView
in iOS 12, and 0.57 likely to reach stable right around the same time as iOS 12 is released to the public, I believe it's worth cherry-picking all of these onto 0.57-stable
:
We have a blog post scheduled which will talk about these changes. People can opt in to the WKWebView
through a new useWebView
prop, so this should be a relatively safe change.
(Comment from @hramos: This comment has been hidden as off-topic. WebView's future has is being discussed over at https://github.com/react-native-community/discussions-and-proposals/pull/3)
Great news with moving to/adding WKWebView!
This is likely offtopic, but I'm stuck using abandoned https://github.com/alinz/react-native-webview-bridge due to this: https://github.com/facebook/react-native/pull/9762#issuecomment-260583009. Would be great to allow setting window.postMessage
to override any existing one in an arbitrary webpage, or avoid name collision by moving RN's injection to window.rnPostMessage
. Had a long discussion before on #9762 and don't remember where else on this and it didn't go anywhere.
Where should a discussion on this be had? Alongside or after the work on adding WKWebView, which as I understand it has new APIs which makes implementing this easier? I'm willing to investigate and implement if lack of interest is the issue with having a functional, non-colliding window.postMessage
. I just need direction on how to approach getting this into RN, if it's wanted. As I need this in my app, and I want to move off unmaintained react-native-webview-bridge
.
👋 thanks for the comments, I believe that it may be worth creating an rc1 as soon as a PR for this workaround is created&merged (https://github.com/facebook/react-native/issues/20710#issuecomment-414631827).
That said, I think we will not move to 0.57.0 until babel 7.0 is released (which should happen this week) in order to prevent more chaos caused by semver of the beta.
I agree, time for next RC once that one lands. Generally speaking I would be against cherry-picking all the WebView related work in scope of this release, but given the timing and possible delays that can occur while releasing next stable release of React Native, I think it's a safe move as explained by Hector.
On Wed, 22 Aug 2018 at 11:00 Lorenzo Sciandra notifications@github.com wrote:
👋 thanks for the comments, I believe that it may be worth creating an rc1 as soon as a PR for this workaround is created&merged (facebook/react-native#20710 (comment) https://github.com/facebook/react-native/issues/20710#issuecomment-414631827 ).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/react-native-community/react-native-releases/issues/34#issuecomment-414963311, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWcxt4kB4IhtH4lE1TYzFRSZYh4Ziueks5uTR2XgaJpZM4VCx2F .
Guys I hope this comment is not off topic, but it's really worrying me. 0.57.* is about to be broadly used and this serious issue is yet not handled.
https://github.com/facebook/react-native/issues/8615
As far as I know NetInfo is malfunctioning and I have no idea what makes it miss-behave. If there's another place to leave that comment let me know and I'll delete it from this thread, but it seems like this thread is generic discussion about 0.57
Thank you.
@SudoPlz as stated in the first comment of this issue
In other words, if you cannot point to a particular commit on master, then your request likely belongs as a new issue in http://github.com/facebook/react-native/issues.
That said, I also suggest you check this comment if that issue is still present for you.
EDIT: I've cherry-picked all the commits discussed above in the 0.57 branch (and tested locally that it still works, npm start
aside), just waiting for a confirmation on merging this https://github.com/facebook/react-native/pull/20790 then I guess we'll proceed to release a rc1.
Please cherry-pick https://github.com/facebook/react-native/commit/9a77ff593bf83a3326e6237bb877e7abc437da96 to fix the bundler regression from https://github.com/facebook/react-native/issues/20712.
Also, thank you for rc2. The rc1 build was all kinds of broken.
Please fix NetInfo issue
@assafb81 this has been mentioned several times - please limit requests to cherry-picks from commits on master. Any future comments of this type will be hidden without explanation.
0.57.0-rc.1 became briefly available today, but it was missing Android artifacts. It was un-published, and 0.57.0-rc.2 is now on npm with all cherry-picks requested up to @kelset's comment above.
facebook/react-native@9a77ff5 has been cherry-picked, alongside facebook/react-native@e61176d650e2b5fe51dd6cd4c429ff47a1a9b1dc. These will make it into rc.3.
ok @hramos, thanks
Thanks @hramos! Aside from those 2 commits, I've cherry picked https://github.com/facebook/react-native/commit/79fe925f1daa053d5a5d92a228e5c7beff565ab4
Let's see if anything else pops out from devs using rc2, if not I feel like we can release rc3 soon-ish.
Would love it if this could be included in rc3 - https://github.com/facebook/react-native/commit/6e356895e79fb92640295a14483af1a430732247
It means we can start making PRs to upgrade all of the RN plugins to use the new gradle keywords instead.
I tested locally the branch with the "new" 3 commits mentioned above
and on macOS now (thanks to @rafeca's commit!) everything seems to be working fine, the run-XXX
not spawning properly the packager is fixed.
So I think we can proceed to do a rc3
release.
Related to @MarkOSullivan94 's request, in order to cherry pick that commit it's actually necessary (to avoid conflicts) to cherry pick:
That said, I also tested locally the branch with those extra 5 commits and everything is still ✅ on my side, so unless @hramos or anyone else has strong opinions against, I feel like we could add those 5 commits and then proceed with rc3
.
I'm OK with cherry-picking these, if test_android
remains green after adding them to 0.57-stable
. It's currently red on master (https://circleci.com/gh/facebook/react-native/50086), and I have yet to investigate which specific commit introduced the regression.
@hramos let me know what is the result of your debugging - I was facing some issues with running Detox on the master that could be related.
I am also okay with cherry-picking the aforementioned commits.
Seeing as other webview commits were cherry picked, could we cherry-pick facebook/react-native@e6b305b?
It would mean having webviews running injected javascript work much better on android
I want to add to @nadinelyab in advocating https://github.com/facebook/react-native/commit/e6b305b722a8f52fad8ac8bf9f95204fa2192944 to be cherry picked. I have hit multiple cases on Android of injected JS on Android not working which this PR describes as fixing. Breakage on Android webview that works on iOS in my app. Having these fixed with a single PR would be much appreciated.
Yeah I think we can cherry pick that, not sure about when because we need to check some tests that are failing atm.
Glancing over the master commits, I think these may be also worth considering:
And these two commits by @rafeca:
I've cherry-picked everything requested since rc.2, with a few exceptions:
I think we're at a point where we can focus on making sure there's no major blockers in this release, so we can promote 0.57 to stable soon.
As always, let's keep the discussion focused on getting 0.57 out the door -- avoid commenting on this thread unless you're requesting a cherry pick of a certain commit that's already on master
. The best way to prioritize getting something fixed is by sending a PR to the RN repo.
On https://github.com/facebook/react-native/commit/e6b305b722a8f52fad8ac8bf9f95204fa2192944, I can confirm though not extensively tested, that /* comment */
blocks on Android are no longer needed in my app for injected JS inside webviews, // comment
now works just like in iOS.
I'm on rc.0.
The commit https://github.com/facebook/react-native/commit/1f88a7111d1a64910a4bfab322820406250081dc is getting reverted on master soon. This commit is in the 0.57 RC, therefore we should cherry-pick the corresponding revert commit once it lands on master.
I'll edit my comment once the revert commit is on master.
Update: The commit https://github.com/facebook/react-native/commit/e8c7cb1c04c583219c99c13657d3038776e968c6 should be cherry-picked into 0.57.
Babel 7 is out of beta
Would be awesome to include Babel 7 out of the box for 0.57, since Babel 7 supports Typescript :) The current release candidate still depends on "@babel/core": "7.0.0-beta.56"
.
@janhesters The current changelog for the 0.57 release says that there is now integrated TypeScript support in the Metro bundler through Babel 7: https://github.com/react-native-community/react-native-releases/blob/0.57/CHANGELOG.md
Yes, we will release 0.57.0 once we are supporting babel 7.0.0. That will take a few days, and we are still planning an rc4
with babel 7.0.0 before 0.57.0 so that it can be tested.
Alright so metro@0.45 is now on master thanks to @rafeca with https://github.com/facebook/react-native/commit/169812f9ce60317dd7320384007879be16278678 we can cherry pick it and create the rc4 @hramos :tada:
Can we add this please? https://github.com/facebook/react-native/commit/f94521244798f859648d1769f397102c06d763f0
Related issue: https://github.com/facebook/react-native/issues/20926
Update: I've cherry picked all of @rafeca's commits for Babel 7.0.0 / Metro support, plus https://github.com/facebook/react-native/commit/f94521244798f859648d1769f397102c06d763f0 (as requested by @birkir) and https://github.com/facebook/react-native/commit/03476a225e012a0285650780430d64fc79674f0f (cc @empyrical, @matthargett).
In my local test, everything went smooth - so I proceeded to push those to the branch.
I feel like we could release an rc4
as is (so that people can test it over the weekend), but before I'd like to see if this commit (https://github.com/facebook/react-native/commit/a549a5377e917f7a4f59c485448b503b43e04d10) fixes the tests for https://github.com/facebook/react-native/pull/20854 - because I think we need to have this PR merged & cherry picked for 0.57.0.
Conversation on this thread are limited to 0.57 releases major issues and backport (cherry-pick) requests from commits that are already on master.
An example of a good such request is a bug fix for a serious issue that has been merged into master but did not make the 0.57 RC cut.
In other words, if you cannot point to a particular commit on master, then your request likely belongs as a new issue in http://github.com/facebook/react-native/issues.