react-native: Android builds with New Arch fail on Windows build host

Description

The following line is wrong, because glob expects patterns with / separators, even on Windows; but when the codegen is executed on Windows the file will contain \ separators, causing that query not matching anything:

https://github.com/facebook/react-native/blob/ca0d565a3c9729a68f71bb5572c9971a6ce85d2a/packages/react-native-codegen/src/cli/combine/combine-js-to-schema-cli.js#L25

Changing that line into:

.sync(`${file.replace(/\\/g, '/')}/**/*.{js,ts,tsx}`, {

fixes the issue (well, I verified that codegen then matches expected files there, but it still does not generate expected outputs, so I am still looking for other issues down the line).

React Native Version

0.71.4

Output of npx react-native info

N/A

Steps to reproduce

N/A

Snack, code example, screenshot, or link to a repository

N/A

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 21 (20 by maintainers)

Commits related to this issue

Most upvoted comments

Hey @cortinico , at last I arrived to do a rapid test, trying to build the example app of my lib for Android on Windows with the new RN arch, and it still does not work for me 😦 image

According to my understanding of this log piece, it seems the JNI project generated by RN Codegen easily hits the CMake restriction on the maximum path length on Windows. Perhaps setting in the generated CMakeLists.txt that CMAKE_OBJECT_PATH_MAX variable, mentioned in the log, to a larger value will help. Though, as I don’t really need myself to build for Android on Windows, I probably won’t look deeper into it in the nearest future. Just leaving this message for a record, and probably you may re-open the ticket.

I usually like to keep my tickets open until the fix is released with a regular version of a product, and the issue is verified to be fixed by it. Especially in this case, I have no idea yet whether that and other PRs will completely fix the problem, or not.

Great I’ve assigned this to you so we know you’re on top of it. I general we tend to close issues more proactively as we have so many, and we close issues once a fix lands on main and eventually re-open. I’m fine keeping this open though

Sorry … I got extremely busy last week … Adding @rasaha91 and @shivenmian who can help as well .

cc @ZihanChen-MSFT maybe you know how to help here?

@cortinico I’ve changed the PR. It turned out that windowsPathsNoEscape option, I used in the previous variant, requires glob@9+, and the current codegen dependency is glob@7.1.1. Updating glob is a bit too much for me, because flow-typed does not have definitions for v9+, and I don’t want create it myself at this time. So, I fell back to the separators replacement in file string. Tested it works, and the PR currently fails just one test in Circle, and that failure does not seem related to my change.

I don’t normally develop on Windows but I do have a windows machine and can help debug.

Same here 😅 I just happened to enter a rabbit hole with developing @dr.pogodin/react-native-static-server library, and although not many people use it yet, some already asked about Windows support, and that’s how I bumped into this issue here 🤷‍♂️

Yeap, I’ll probably do the next week. Still have to figure out what else doesn’t work right there.