0.57.0 Discussion about releases HOT 136 CLOSED

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.

from releases.

0.57.0-rc.3 is now available.

I've cherry-picked everything requested since rc.2, with a few exceptions:

• facebook/react-native@e6b305b was requested by @nadinelyab and @fungilation, but that commit has been a part of the RC since rc.0.
• facebook/react-native@e4621f4 requires a new version of Metro to be deployed to npm, so it will have to wait for the next release

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.

from releases.

Babel 7 is out of beta

from releases.

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.

from releases.

@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 💪

from releases.

Will this issue be resolved by 0.57:
facebook/react-native#19953

When is 0.57 due for release? It has been frustrating not being able to use react native on Windows.

from releases.

While testing the branch we got stuck on this facebook/react-native#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.

from releases.

Would love it if this could be included in rc3 - facebook/react-native@6e35689

It means we can start making PRs to upgrade all of the RN plugins to use the new gradle keywords instead.

from releases.

Update: I've cherry picked all of @rafeca's commits for Babel 7.0.0 / Metro support, plus facebook/react-native@f945212 (as requested by @birkir) and facebook/react-native@03476a2 (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 (facebook/react-native@a549a53) fixes the tests for facebook/react-native#20854 - because I think we need to have this PR merged & cherry picked for 0.57.0.

from releases.

@jonathanglasmeyer open a dedicated issue for that.

I agree with @hramos statement, we want to get to 0.57.0 now without too many new commits.

Moreover, I haven't seen any major "release-blocker" issues so I think we may want to proceed to 0.57.0 soon.

from releases.

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

from releases.

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 😅).

from releases.

Is there any chance of this commit entering version 0.57?

from releases.

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.

from releases.

Since we updated Gradle, should we also include facebook/react-native@4dfdec9 so to release 0.57 with all Gradle parts updated?

Then again, it's not a priority since the old compile configuration will be removed only at the end of the year in a future update.

from releases.

Update on my previous comment:

• one of @rozele's PRs landed, so we need to cherry-pick this facebook/react-native@c5297c7 and wait for Metro 0.43.7 to be releases since this commit is not published yet facebook/metro@387d487
• until Metro 0.43.7 is released this can't be merged facebook/react-native#20706 (and cherry pick it)
• we'll also need to cherry pick this facebook/react-native#20751 (context: facebook/react-native#20712 (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.

from releases.

I tested locally the branch with the "new" 3 commits mentioned above

• facebook/react-native@79fe925
• facebook/react-native@e61176d
• facebook/react-native@9a77ff5

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:

• facebook/react-native@874cca1
• facebook/react-native@f884a1b
• facebook/react-native@7ff9352
• facebook/react-native@044b399
• (and finally) facebook/react-native@6e35689

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.

from releases.

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.

from releases.

Thanks @hramos - It went through, 0.57.0-rc.4 is out

from releases.

Thanks for taking care of that @hramos!

@fungilation I think you should only need the bridge version, and you should check the package.json for making sure which version of Metro is the latest on branch.

When we will release 0.57.0 (which is, hopefully, soon, based on the feedback on rc4) we'll make sure to include a list of manual steps to upgrade your apps.

from releases.

We should cherry pick @ikesyo’s suggested WKWebView commit and promote to stable. I’d leave the TextInput commit for the next release. We have to cut at some point; after all, we should really be only cherry picking commits for fixes that remained incomplete (as in, the release was cut when some commits related to the fix had not landed yet), as well as fixes for any major issues that arises during the RC process.

from releases.

WKWebView cherry-pick request

A stack of commits landed on master a few days ago, which bring support for WKWebView-backed WebViews 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:

• facebook/react-native@1442c26
• facebook/react-native@3703927
• facebook/react-native@7a6dd98
• facebook/react-native@e5f95ab
• facebook/react-native@1741fe9
• facebook/react-native@90e85a4
• facebook/react-native@0022354
• facebook/react-native@03b57d9
• facebook/react-native@1584108
• facebook/react-native@a997c0a
• facebook/react-native@4ca949b
• facebook/react-native@7217630
• facebook/react-native@1af17f1
• facebook/react-native@215fa14
• facebook/react-native@bacfd92
• facebook/react-native@95801f1
• facebook/react-native@b18fdda
• facebook/react-native@28b058c
• facebook/react-native@33b353c

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.

from releases.

Cherry-picked, waiting for CI and will release rc4

from releases.

from releases.

facebook/react-native#20854 - has been synced with master and all CI stages passing now 👌

from releases.

Update on 0.57 please? I'm not seeing any RC on https://github.com/facebook/react-native/releases

from releases.

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".

from releases.

They are having issues with the new NDK, @Salakar if you want to follow what is happening on a branch I use this syntax https://circleci.com/gh/facebook/react-native/tree/<branch_name>, for example https://circleci.com/gh/facebook/react-native/tree/0.57-stable

from releases.

I was out sick the past week, so I missed all of these updates. I'm re-tagging 0.57.0-rc.4 and having it go through Circle again.

from releases.

@fungilation "babel-core" is the old implementation, the new one is "@babel/core". The reason why we suggest to have "babel-core": "7.0.0-bridge.0" it's because it's a special version that should help you handle scenarios in which you may have old packages that still use babel 6.

That said, again, pls keep this issue solely on the topic of the release and eventual commits to cherry pick.

from releases.

@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 🔥🤓

from releases.

It would be nice to see facebook/react-native@fd744dd in this release.
facebook/react-native#20155 is quite annoying currently.

Thanks.

from releases.

Will there be a fix for animations on Android? This issue got closed even though it was unresolved. I'm asking because I'm currently facing issues with animations on Android in the app that I'm building.

from releases.

Can we get facebook/react-native@2307ea6 cherry-picked into next release?

Actually, we're unable to mask an input or append a validation 'cuz TextInput is not taking the value being passed as a prop as the actual input value.

from releases.

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

from releases.

@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.

from releases.

@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@e61176d. These will make it into rc.3.

from releases.

I want to add to @nadinelyab in advocating facebook/react-native@e6b305b 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.

from releases.

RC4 seems to be tagged - but no release on NPM?

from releases.

from releases.

@janhesters Just the tag in the react-native repo: https://github.com/facebook/react-native/tree/v0.57.0-rc.4

from releases.

Anyone else getting duplicate module issues on rc4? Looks like metro-visualizer installed as part of react-native causing it:

EDIT: resolved, this was an invalid providesModuleNodeModules param on metro.config.js causing the issue - thanks @Titozzz for helping me out.

(node:91698) UnhandledPromiseRejectionWarning: 

Error: jest-haste-map: @providesModule naming collision:
  Duplicate module name: react

  Paths: 

	<PROJ_ROOT>/node_modules/react/package.json 
		collides with 
	<PROJ_ROOT>/node_modules/rc-hammerjs/node_modules/react/package.json

This error is caused by a @providesModule declaration with the same name across two different files.
    at setModule (<PROJ_ROOT>/node_modules/jest-haste-map/build/index.js:462:17)
    at workerReply (<PROJ_ROOT>/node_modules/jest-haste-map/build/index.js:512:9)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

yarn why rc-hammerjs outputs:

Should react-native be more explicit as to what metro packages it requires rather than blanket requiring all of metro which adds all the metro packages (package.json)?

yarn why metro-visualizer:

Quite a lot of unnecessary packages?

from releases.

facebook/react-native@0bf56e0 should be cherry-picked to make the new WKWebView backend usable (the feature is listed in the 0.57 changelog's Highlights section #40).

from releases.

Once it's merged, can we cherry-pick facebook/react-native#20705 onto 0.57-stable and cut another RC for react-native-windows and react-native-dom. +@vincentriemer

from releases.

👋 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)).

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.

from releases.

Please cherry-pick facebook/react-native@9a77ff5 to fix the bundler regression from facebook/react-native#20712.

Also, thank you for rc2. The rc1 build was all kinds of broken.

from releases.

The commit facebook/react-native@1f88a71 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 facebook/react-native@e8c7cb1 should be cherry-picked into 0.57.

from releases.

I haven't actually tagged rc.4 yet, so this step was expected to fail anyway. This failure seems very suspicious and should be fixed (CC: @hramos how you were doing that previously?)

Going to cut it now and see where it goes.

from releases.

@Titozzz running ssh-keyscan github.com >> ~/.ssh/known_hosts might work to resolve that issue - whether that's needed as part of the script I'm not sure.

Something like:

exec('ssh-keyscan github.com >> ~/.ssh/known_hosts', {silent: true});

before line 65 of the publish-npm.js script maybe.

@grabbou Re: what would be nice to see in the 0.57 release;

Android is missing native Promise reject with a userInfo WritableMap support and also nativeStack support (closes TODO(8850038)).

Have pushed up #20940 for this. Am aware the requirements are master only but this would have been PR'd 1-2 weeks ago if I wasn't in the middle of sorting facebook/react-native#20854 first to get master passing on CI again (it also includes Babel 7 + Metro upgrades + fixing broken CI stages).

from releases.

Hi! It would be cool to see facebook/react-native@1cc29c5 in the next RC cut.

from releases.

facebook/react-native@1cc29c5 has been cherry-picked, but didn't make it into rc.4.

from releases.

@yurykorzun that's interesting. I've upgraded (by react-native-git-upgrade) to rc4, and

@babel/core in my yarn.lock shows 7.0.0, but
babel-core shows multiple 6.x deps that resolves to 6.26.3.

I can run my app in android emulator fine on Windows 10 with this though. What's the difference between babel/core and babel-core anyway?

I searched through RN's github repo, and the only reference to "babel-core" (not babel/core) is in https://github.com/facebook/react-native/blob/master/react-native-git-upgrade/package.json, which specifies ^6.18.0.

@kelset, is this correct or should it be version bumped (for git-upgrade and manual upgrade)? To "babel-core": "7.0.0-bridge.0" or just "babel-core": "7.0.0"?

from releases.

The correct version for React Native 0.57 should be 7.x.x. As of rc.4 we upgraded to the stable Babel 7.

from releases.

https://github.com/ueno-llc/react-native-starter

Fully working with typescript and everything, literally only thing I had to do was bump the version and modify the metro config a bit.

Try removing the npm/yarn lockfile and install again with just babel 7 (no bridge)

from releases.

@matt-block yes, we should. Unfortunately, it raises one important concern that I have - I described it in the commit. Let's look at it and discuss it for a moment before we decide to cherry-pick it. I am afraid it might be deal breaking for existing users of React Native link.

That said, I could potentially spend some time tomorrow getting this fixed, as we have to ship it (who wants stable release with warnings), yet we need this one fixed and fully supportive of both formats, at least for one release.

from releases.

Before we reach 0.57.0 we need to be sure this is fixed/closed: facebook/react-native#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.

from releases.

@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.

from releases.

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.

facebook/react-native#20710

from releases.

A few issues and PRs we should try to have merged (and cherry picked) for 0.57.0:

• facebook/react-native#20703 fixed via facebook/react-native#20706
• facebook/react-native#20705
• facebook/react-native#20662
• we should make sure to have metro version that uses this facebook/metro#223

from releases.

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.

from releases.

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.

from releases.

@grabbou Awesome news! Thank you very much.

from releases.

@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 - facebook/react-native@c5297c7 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.

from releases.

(Comment from @hramos: This comment has been hidden as off-topic. WebView's future has is being discussed over at react-native-community/discussions-and-proposals#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: facebook/react-native#9762 (comment). 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.

from releases.

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.

facebook/react-native#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.

from releases.

@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 facebook/react-native#20790 then I guess we'll proceed to release a rc1.

from releases.

Please fix NetInfo issue

from releases.

ok @hramos, thanks

from releases.

Thanks @hramos!
Aside from those 2 commits, I've cherry picked facebook/react-native@79fe925

Let's see if anything else pops out from devs using rc2, if not I feel like we can release rc3 soon-ish.

from releases.

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.

from releases.

@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.

from releases.

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:

• facebook/react-native@e2f2e41
• facebook/react-native@3b688ae

And these two commits by @rafeca:

• facebook/react-native@dd0900a
• facebook/react-native@e4621f4

from releases.

On facebook/react-native@e6b305b, 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.

from releases.

@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

from releases.

Alright so [email protected] is now on master thanks to @rafeca with facebook/react-native@169812f we can cherry pick it and create the rc4 @hramos 🎉

from releases.

Can we add this please? facebook/react-native@f945212

Related issue: facebook/react-native#20926

from releases.

As the RC4 deploy failed due to

Maybe we can cherry pick facebook/react-native#20854 and release the RC4 with, hopefully all the commits we will need for React Native 0.57? Also, is there anything we can do to fix this step on Circle CI, or is this facebook internal?

from releases.

@grabbou facebook/react-native#20854 - addressed all CI failures on master - or are these other CI issues? (it's also approved for importing already)

All CI stages are passing on that PR - the last failure was the Friday/Saturday NPM outage (which was also likely the cause of the import failure)

from releases.

@Titozzz It's been stale for two days actually.

from releases.

It seems react-native docker build image is circleci/android:api-27-node8-alpha but there is also
circleci/android:api-27-ndk-r17b at docker hub. api-27-node8-alpha don't have NDK in it but api-27-ndk-r17b don't have node and yarn. Therefore react-native can't use both of them.

from releases.

There is an circleci task to install NDK on the node8 image

edit: Maybe the install ndk steps have to be added to the publish step:

  publish:
    <<: *android_defaults
    steps:
      - checkout

+      - run: *create-ndk-directory
+      - restore-cache: *restore-cache-ndk
+      - run: *install-ndk
+      - save-cache: *save-cache-ndk

      - restore-cache: *restore-yarn-cache
      - run: *yarn

from releases.

@birkir You are correct it has Install Android NDK setup on test_android step but not in the publish step. It is removed at this commit.

from releases.

Any difference in upgrade procedure, coming from rc1? Upgrading with react-native-git-upgrade, do we still need this in package.json dependencies: "metro-react-native-babel-preset": "0.43.5", and

  "resolutions": {
    "@babel/core": "7.0.0-beta.56",
    "babel-core": "7.0.0-bridge.0"
  }

?

from releases.

@kelset Will it possible to replace global babelHelper and @babel-external-helper to @babel/runtime for better compatibility to third-party library since RN0.56.0+ is using babel7, some helpers such as applyDecoratedDescriptor is not defined in global babelHelper

from releases.

@wangshangming could you open a PR for that? I think that it would be easier to visualise and understand how it affects the codebase.

That said unless it fixes a precise bug that is a release-blocker I don't think it will make it for 0.57.0. But maybe for a future minor release.

from releases.

This might be a nooby question, but how can I find the git repository for rc4? 😊

from releases.

@wangshangming @kelset There is a PR open in metro to replace babel helpers with the babel runtime. Hopefully it will be included in the next major release of metro?
facebook/metro#198

from releases.

@newyankeecodeshop yeah that's a way to solve the issue but still a better way to remove the babelHelper/regeneratorRuntime since it can not always catch up with the latest babel-helper

from releases.

thanks for the link! Anyway let's keep this conv about existing commits and/or issues potentially blocking the release - again, @wangshangming, a PR would be the best way to discuss it :)

from releases.

@Salakar I've updated my app to 0.57.0-rc.4 from 0.56 with nearly no issues. The only duplicate I had is due to the fact that I have multiple react-native In my workspace yet I manage to deal with the blacklistRE param in the metro.config.js.

I'd like to make sure that 0.57 release is as smooth as possible for everyone, can you DM me on twitter so that we can find out what's wrong with your setup without polluting this thread too much 😅 ?

from releases.

Happy to report that upgrading to rc4 caused minimal fuss. I could even take out metro-react-native-babel-preset dep and babel-core resolutions in my package.json, I've verified in my yarn.lock that metro correctly resolves to 0.45.1 and babel* resolves to 7.0.0 currently.

Minimal fuss except facebook/react-native#21020. I suggest a one liner change in gradle-wrapper.properties before 0.57 release.

from releases.

@Titozzz have DM'd you - thanks 👍

EDIT: resolved, this was an invalid providesModuleNodeModules param on metro.config.js causing the issue - thanks @Titozzz for helping me out.

from releases.

Why babel 6 is installed along with babel 7?
I have an issue with "Unexpected token '...'. Expected a property name." in one of my projects after updating to 0.57 rc4. Can't figure out it if it's because of the update or I have some missing configuration.

yarn why babel-core

[1/4] Why do we have the module "babel-core"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "[email protected]"
info Reasons this module exists
   - "react-native#metro" depends on it
   - Hoisted from "react-native#metro#babel-core"
   - Hoisted from "react-native#fbjs-scripts#babel-core"
   - Hoisted from "jest#jest-cli#jest-runtime#babel-core"
   - Hoisted from "jest#jest-cli#jest-config#babel-core"
   - Hoisted from "react-native#metro#babel-register#babel-core"
   - Hoisted from "react-native#metro#metro-visualizer#emotion#babel-plugin-emotion#babel-core"

from releases.

@fungilation

I searched through RN's github repo, [...]

I would recommend looking in the Metro repository, I think that could be where it's coming from.

from releases.

The bigger question before even where it's from, is what is the intended/correct version(s) post-install for babel/core, babel-core.

from releases.

I think what is really important is that your build is done with Babel 7 and that Babel 6 does not conflict with that. If then we still have a dependency such as a cli that require babel-core or babel-runtime to run, that's fine and it can get bumped later if needed.

from releases.

Hey guys, since 0.57.0-rc.4 added support for "out of the box typescript" I decided to give it a go and stumbled across following issue:

It seems that it compiles .ts and .tsx files fine, however I have module resolution set up in my repo and am getting following error:

Loading dependency graph, done.
error: bundling failed: Error: Unable to resolve module @myApp/services/validation from /Users/me/Documents/Repositories/myApp/packages/myApp/src/store/AuthStore.ts: Module @myApp/services/validation does not exist in the Haste module map

This used to work with typescript setup pre 0.57.x. Am I wrong in assuming that rn will respect existing tsconfig.json files as default or is additional configuration in babel needed for this?

from releases.

I decided to try to narrow down the problem I was having with 0.57 rc4 and try to find where the exception Unexpected token '...' was coming from. After adding react-navigation to the empty project I get the same error right away. It looks like react-navigation cannot resolve the object rest spread operator plugin. It works with RN 0.54

This is probably off topic and I will post it to react-navigation issues.

from releases.

Just tracked down an issue while trying to get a running project with RC4: the react-native local-cli fails with

ReferenceError: regeneratorRuntime is not defined
    at getCliConfig (/Users/jwerner/projects/rn-test/Foo/node_modules/react-native/local-cli/core/index.js:128:44)

when babel is setup with babel.config.js:

// babel.config.js
module.exports = {
  "presets": ["module:metro-react-native-babel-preset"]
}

Everything works when the same babel configuration is applied in the old .babelrc format.

I traced down the problem by inserting console.logs in node_modules/@babel/register/lib/node.js, function compile. When using babel.config.js you can see that all plugins of module:metro-react-native-babel-preset are being applied to the node_modules/react-native/local-cli/core/index.js file; when using .babelrc that's not the case. The code breaks because apparently regeneratorRuntime call is inserted, but babel/polyfill (or regenerator-runtime/runtime) import is not happening.

Repository with working state
With a broken state

Is this behaviour known? How are users expected to make use of babel.config.js?

from releases.

I tried to run my app with rn 0.57rc 4 but it seems that weird things are happening when transforming local-cli/server/server.js. I migrated from babel-preset-react-native to metro-react-native-babel-preset

> node node_modules/react-native/local-cli/cli.js start

/Users/michaelknoch/dev/flow/smartphone-app/node_modules/@babel/core/lib/transformation/normalize-file.js:209
    throw err;
    ^

SyntaxError: /Users/michaelknoch/dev/flow/smartphone-app/node_modules/react-native/local-cli/server/server.js: Unexpected token, expected ";" (9:32)

   7 |         })
   8 |       );
>  9 | /* remotedev-server end */ code is licensed under the MIT license found in the
     |                                 ^
  10 |  * LICENSE file in the root directory of this source tree.
  11 |  *
  12 |  * @format

from releases.