facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
119.46k stars 24.37k forks source link

transform.forEach is not a function #13765

Closed hanih closed 6 years ago

hanih commented 7 years ago

I got the following error in the simulator when running a newly created project without updating react native cli:

transform.forEach is not a function

I had node version 4.7.1. The problem happens on both iOS and Android I updated node to latest version and updated RN cli and created a new app and it worked fine but the one created before still gives the same error even after deleting and reinstalling node modules using npm install

long-nguyentien commented 7 years ago

I am also getting this issue, even with Hello World sample project.

johnckendall commented 7 years ago

Yes, here too. I've updated to the latest everything and still can't get a newly created project to run without that error. Even after attempting to update everything and/or nuking and re-installing everything including node modules.

running latest OS X / Xcode / node (6.10.3) / npm / react / react-native-cli / etc

UPDATE: Ok , this is really weird. All the tests and experiments I've done up to this point have been with using a project name of "AwesomeProject". And they all failed with that same error.

Just now I used a different project name but did the exact same steps... and it worked. That's just messed up.

dilipkumar2k6 commented 7 years ago

For me, it is still failing for same reason. I even tried a new name.

long-nguyentien commented 7 years ago

I found a solution for myself yesterday. I tried to reinstall new node by command 'brew install node', and the problem get solved. In my case, my node was previously installed from dmg file(downloaded from website), not from the brew command. Therefore this could be a reason why node didn't work as expected. Hope it could help you too

willgvfranco commented 7 years ago

Im getting this problem too.. Already updated the node and changed the name of project.

EDITED: As @siamakf said, its random, i created newly projects until it finally worked.

siamakf commented 7 years ago

I'm having this issue as well. It seems inconsistent; some newly initialized projects work and some give this message.

kasun90 commented 7 years ago

I have tried creating new projects. Issue still exists. All the components are installed and no build errors. What am I doing wrong? I'm new to react native.

AnselmMarie commented 7 years ago

After creating multiple projects with no success my workaround is to downgrade React Native until the issue is fixed.

kasun90 commented 7 years ago

Update everything (brew update, npm update), uninstall node, watchman and react-native-cli and do a clean install again. https://facebook.github.io/react-native/docs/getting-started.html

That worked for me

JoorgeFerrari commented 7 years ago

I also have this problem, so far i found no solution. Following the issue.

audente commented 7 years ago

I reinstalled as @AnselmMarie suggested, AND I also changed the project name. It's working for me now.

terryttsai commented 7 years ago

I was also getting this problem trying to run the sample app here https://facebook.github.io/react-native/docs/getting-started.html

I finally got it to work on my Android by downgrading my React Native version to 0.43.4

eperezf commented 7 years ago

I'm having the same error here on macOS Sierra.

Node version 4.6.1 React Native version 0.44.0

fergo125 commented 7 years ago

I am having the same problem on Windows, any solution will be greatly appreciated...

sunnylqm commented 7 years ago

Seems it's a problem with Node 4.x Try to upgrade Node

uraees commented 7 years ago

thanks @terryttsai , your idea worked and awesome !

eperezf commented 7 years ago

@sunnylqm Node is now updated to 6.10.3 and the error is still present.

ahmetalsan commented 7 years ago

same problem on osx

bdgeyter commented 7 years ago

I was also on node 6.x, which I'm pretty sure I installed from nodejs.org website. I reinstalled node using brew install node. I'm now on node 7.x.

Running react-native run-ios I could right away notice a much longer compile time.

Sure enough, the problem is solved for me.

terryttsai commented 7 years ago

@bdgeyter thanks, I uninstalled and reinstalled node using brew install node to install node 7.x. Now the issue went away for me.

jesseaborden commented 7 years ago

Tried a bunch of solutions here. Falling back to an earlier version did the trick for me. Thanks @AnselmMarie !

divyanshupathak commented 7 years ago

I have the same error. Node version - 6.10.3 react-native version - 2.0.1 npm version - 3.10.10 Can anyone resolve this ? Thanks in advance.

skumancer commented 7 years ago

Having this same error.

node v7.10.0 watchman 4.7.0 react-native-cli 2.0.1 react-native 0.44.0 npm 4.2.0

Can't get it to work from a clean install.

scarlac commented 7 years ago

We recently added Lottie and Firebase Analytics to our RN project and then I saw this error. Tried reinstalling node/npm version (7.10.0), yarn (0.24.5), watchman (4.7.0), etc. And still had this error. I tried a clean checkout of our project, removing the Pods/ folder, removing node_modules and reinstalling. Also tried resetting iOS simulator. Nothing worked. Obviously, turning off debug mode worked (because then the invalid prop is no longer validated) but that's not a viable solution for development.

Then I tried actually debugging the issue by inserting console.log(...) statements. Initially no change. Then I enabled live module reload and the remote debugger. No change. Added another log statement in another RN file and suddenly the app started working! I removed the log statement and the app kept working.

I can't say exactly what caused the change. Co-worker didn't have this issue. Seemed to have exactly the same setup. Doing changes in the project installation of RN with hot module reloading caused an error (too many components being reloaded) so perhaps something got recompiled along the way. It's odd since I've removed and reinstalled node_modules so many times. I'd suggest others who encounter this issue to try something similar.

JoeyVinyard commented 7 years ago

I had this same problem. I fixed it by updating to the latest node(7.10.0 at the time of writing this), then I completely torched the boilerplate project, rebuilt it, and it compiled without a problem.

mhkhung commented 7 years ago

0.44 is crap.. 0.43.4 works..

react-native init --version 0.43.4 AwesomeProject

flyher commented 7 years ago

react-native 0.43.4 works and 0.44,0.46 cannot work. you can use this package.json

{
    "name": "AwesomeProject",
    "version": "0.0.1",
    "private": true,
    "scripts": {
        "start": "node node_modules/react-native/local-cli/cli.js start",
        "test": "jest"
    },
    "dependencies": {
        "react": "16.0.0-alpha.6",
        "react-native": "0.43.4"
    },
    "devDependencies": {
        "babel-jest": "20.0.3",
        "babel-preset-react-native": "2.0.0",
        "jest": "20.0.4",
        "react-test-renderer": "16.0.0-alpha.6"
    },
    "jest": {
        "preset": "react-native"
    }
}
mikelambert commented 7 years ago

I believe this is due to some Haste/Node packaging nondeterminism bug, that is causing the code to use the top-level npm module merge instead of react-native's built-in Haste module merge.

It's manifesting because the Style validator was being passed as the style param itself. And the style validator (which is a series of functions) will not pass the style validator itself (which isn't expecting functions). I get two errors as a result of this bug:

Digging in, I believe this is a result of module packager getting confused with merge.

In particular, createStrictShapeTypeChecker calls merge(props[propName], shapeTypes), expecting to call Haste's built-in FB merge module.

Unfortunately, in cases where things are broken (ie, all of us above), it appears to import a top-level node module called merge (imported via <-exec-sh<-sane<-react-native). This version of merge mutates one of the parameters when merging, instead of treating both parameters as immutable. Which in our buggy case, causes the passed-in style param to become infected with the style validator dictionary, and then fail style validation.

Unfortunately, I am still not clear what causes the react-native package to import one merge vs the other. Timestamps? inode file ordering? I suspect there's some non-determinism there that's affecting all of us.

I've just filed an issue on the metro-bundler project (which includes the Haste packager) on the underlying bug: https://github.com/facebook/metro-bundler/issues/18 Maybe they can help shed some light on what's going on here...

mikelambert commented 7 years ago

(Updated: with hopefully-improved fix instructions) Wow, a few hours later, I think I have the (stupidly simple) fix:

# Fix Part 1
rm -rf node_modules/react-native/node_modules/merge
npm install merge # install it adjacent to react-native for those who still need it
# Fix Part 2
react-native start --reset-cache

If you're curious for a deeper history as to all the above confusion, read on for my guess at a fuller explanation as to why this bug was hard to fix (though still no understanding of how the cache got corrupted):

As stated above, React-Native was installing a node_modules/merge as well as a @providesModule merge, creating a module conflict. Deleting the nested 'merge module allows the Haste @providesModule to take precedence, and things to work again. A proper haste resolution fix in the bundler is being discussed in https://github.com/facebook/metro-bundler/issues/18#issuecomment-313615368 .

In the meantime, you can install merge at a higher level (if it's not there) to ensure it is available. (Though I don't think it is strictly necessary.) Sometimes an npm install will install it at the top-level node_modules (things work!), and sometimes it will install merge inside the react-native/node_modules (things break!), and I haven't investigated this deeply.

Unfortunately, there is some cached state stored in the watchman temp directories, stored outside of our project directory. My cache got convinced there was a merge conflict (hah!), and so wouldn't resolve things even after deleting the nested merge module. Resetting the cache fixed things for me. This might also explain why the bug was so persistent despite make clean and blowing away node_modules/ and whatnot.

This cache stores full paths to files, which might also explains why any change to the directory paths will avoid the corrupted cache entries and fix things: changing the project name, creating a new project, or checking out a new directory. (But notably, deleting the current directory and recreating it in-place won't fix things.)

The cache files (on Mac) appear to be stored in /var/folders/, which I think will be erased when you reboot the OS. This may explain why other people's problems "randomly" went away.

It appears to try to "update the cache" in response to changed files, which might be mtime dependent. Refetching from NPM would pull in the same timestamps on the actual js files (such as merge/merge.js and Libraries/vendor/core/merge.js), and not trigger any changes or cache updates. But touching all the files would fix it. Or even just adding-and-deleting a log statement to merge.js would fix it.

Oh, and I wish I could have those 7 hours of my life back.

f0rr0 commented 7 years ago

@mikelambert resetting the cache still doesn't solve this issue for me.

mikelambert commented 7 years ago

Ugh sorry. :( Talking a bit more on https://github.com/facebook/metro-bundler/issues/18, I think I realized my diagnosis was half-wrong, and my proposed solution was incomplete.

I would delete node_modules/react-native/node_modules/merge, then reset the cache, and I suspect things will go better for you. (Possibly re-installing merge at the top-level node_modules if necessary...)

I've just updated my above post to reflect this better fix...sorry for making your comment look out of place now.

rraspo commented 7 years ago

So, I don't really know if this will work for someone else, but I ran

npm install prop-types

and it stopped showing this error and working again.

elmarti commented 7 years ago

I've tried all of these steps, still getting undefined is not a function (evaluating 'transform.forEach')

stantoncbradley commented 7 years ago

for anyone else getting this error, my problem was in my code:

WRONG

<Animated.View
  style={{
    transform: { translateY: myAnimatedValue },
  }}>

RIGHT

<Animated.View
  style={{
    transform: [{ translateY: myAnimatedValue }],
  }}>

make sure you wrap your transform in an array!!!

GianniGM commented 7 years ago

tried all of this step, nothing works, same error, same frustration

miyabi commented 7 years ago

This helped us.

react-native-git-upgrade 0.46.4
bohomi commented 7 years ago

using yarn instead of npm did the job for me, worked out of the box!

mikelambert commented 7 years ago

Just a headsup, there is a new version of jest-haste-map 20.0.5 that should have a fix for the problems I encountered (it includes https://github.com/facebook/jest/pull/3984). It's not tagged latest yet, but it's possible that some people are somehow pulling in that version? (I don't know how yarn or react-native-git-upgrade work.)

So if you are still having issues, I would try to find jest-haste-map inside your project's node_modules tree, and upgrade it to 20.0.5, to see if that helps. If it doesn't work, then my best guess is your brokenness is due to a different cause than the one I identified (ie, https://github.com/facebook/react-native/issues/13765#issuecomment-315883578 is an example of a different cause for the same error.)

GianniGM commented 7 years ago

@alinakgh i removed node_modules dir and install with yarn and works for me, thank you a lot!!

Taewa commented 7 years ago

After spend a half day of struggling, just reboot my mac and worked. Inspired by

The cache files (on Mac) appear to be stored in /var/folders/, which I think will be erased when you reboot the OS. This may explain why other people's problems "randomly" went away.

Thanks @mikelambert

ConanChen8 commented 7 years ago

I got the same problem but I solved it in this way: Downgrade your NPM to 4.1.2 remove your node_mdules folder and install it by npm install (with version 4.1.2) run react-native start --reset-cache

this works for me. Please Try!

vwwv commented 7 years ago

I got the same problem; I tried several of the ideas mentioned above but still could not make it work, then I tried building it with yarn instead of npm, and it started working again.

y2k-shubham commented 7 years ago

I had other conflicts too in my project (apart from 'node_modules/react-native/node_modules/merge'), nevertheless, @mikelambert 's solution of resolving just this conflict (rm -rf node_modules/react-native/node_modules/merge) still worked for me. Thanx dude!

MichaelPintos commented 7 years ago

@GianniGM work for me. thx

ngankt2 commented 7 years ago

After trying everything. I tried restarting MacOS, and it works for me! Thanks @mikelambert

The cache files (on Mac) appear to be stored in /var/folders/, which I think will be erased when you reboot the OS. This may explain why other people's problems "randomly" went away

sibnerian commented 7 years ago

s.tantoncbradley's solution worked for me: https://github.com/facebook/react-native/issues/13765#issuecomment-315883578. The issue was setting transform: { val: something } instead of transform: [{ val: something }].

I feel like RN should have a type-check here and throw a better error message...

byoungdale commented 7 years ago

@mikelambert worked for me, except I had to use npm cache clean --force instead of react-native start --reset-cache because react-native start --reset-cache` would just hang and not do anything.

arnazmursidp commented 7 years ago

@stantoncbradley thanks a lot my animation is working!!

stale[bot] commented 7 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. If you think this issue should definitely remain open, please let us know why. Thank you for your contributions.

adamnator92 commented 6 years ago

@mikelambert your solution work, thank mate!