react-native: Packager build error on Windows: "Unexpected identifier" or "Unable to resolve a Haste module"

please help us - Windows developers are human too. We need support too.

While I understand everyone frustration with this Windows issue, let me be extremely clear on the fact that if this issue becomes a series of “me too” comments or worse I’ll lock it.

As mentioned many times before, this is an open source project - so you’re entitled to the level of support you pay for and that’s: none.

I’ve been personally trying to having this fixed since the first RCs of 0.56, but I’m not a Windows user so it’s really hard to check the attempted fixes.

You want to help? Investigate what is causing this issue and submit PRs to fix it (as @gengjiawen has been doing). (in particular, if you are a developer in London or the EU timezone pls DM me on twitter so we can try to create a shorter feedback loop)

All my windows related pr has been merged, you can play with react native code on windows now. Have fun 😃

@gengjiawen I’m aware of this, and other PRs. We just held a day-long event for React and React Native contributors here at the office, and we’re now finishing our roadmap and a proposal to help move PRs along faster. It does require that we take a break from looking at our GitHub notifications for a bit so we can focus, but in the long term it should have a beneficial effect on the repo.

For the time being, please work with any of our other core contributors, and thank you for your patience.

Confirmed metro 0.43.4 works. @kelset @grabbou we can start prepare for a new release. cc @rafeca @hramos .

Reported via https://github.com/facebook/metro/issues/213.

@kelset How about we downgrade metro to 0.42.1 on branch 0.57 ?

Can this become a viable solution to officially support Windows deployment by relying on the Windows Linux subsystem? The great thing with this is the whole RN toolchain would then be the same as Mac/Linux’s by running inside WSL. The setup would obviously be more complicated to have install files on native Windows so it’s exposed to the GUI code editor while still giving fs/executable access from WSL, but having a single Linux-like environment for RN build to support instead of split with Windows’ (which also breaks in all sorts of other “interesting” ways like permissions to create/delete files/folders as I’ve encountered trying to setup my RN env on Windows) seems very appealing. RN also doesn’t need to consider alternative CI testing on Windows either then.

• This: https://stackoverflow.com/a/46375361/2322084
• Revisit https://github.com/facebook/react-native/issues/11483 with Android support having moved to api 26?

PS. My comment was/is not a me too comment. I was highlight different issues I faced while migrating to Windows (from Mac). If you want the community to help, you have to be more specific in terms of what you need in testing. And this is a discussion thread is this not? Agreed that as long as comments aren’t “just” me too. Group hug on helping each other out in moving RN forward, together.

@hramos @rafeca Can we get this done ? This has been bothering windows user for over a month.

so you’re entitled to the level of support you pay for and that’s: none. I cant imagine flutter core team member saing something like this

react-native init EventPlanner --version 0.55.4 npm install --save npm install -g npm-install-peers

This worked for me 😃

Update:

• Metro 0.43.1 still not working, the build on master branch is still broken on windows.
• Release version (gradlew RNTester:android:app:assembleRelease ) not working on latest master branch too.
• The debug fix pr still need to be merged https://github.com/facebook/react-native/pull/19974, still waiting for approval.

Error log for release mode:

> Task :RNTester:android:app:bundleReleaseJsAndAssets FAILED
D:\Developer\react-native\local-cli\cliEntry.js:30
import type {CommandT} from './commands';
       ^^^^

SyntaxError: Unexpected identifier
    at new Script (vm.js:74:7)
    at createScript (vm.js:246:10)
    at Object.runInThisContext (vm.js:298:10)
    at Module._compile (internal/modules/cjs/loader.js:657:28)
    at Module._compile (D:\Developer\react-native\node_modules\pirates\lib\index.js:83:24)
    at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
    at Object.newLoader [as .js] (D:\Developer\react-native\node_modules\pirates\lib\index.js:88:7)
    at Module.load (internal/modules/cjs/loader.js:599:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
    at Function.Module._load (internal/modules/cjs/loader.js:530:3)

@hramos That’s awesome to hear, will the roadmap be shared publicly or just used internally? Would be very helpful to gain some insights from the roadmap.