[0.22] JSX Bundle Hosting Issues on Linux Server #6581
Comments
|
@facebook-github-bot stack-overflow |
|
Hey @daesan and thanks for posting this! @satya164 tells me this issue looks like a question that would be best asked on StackOverflow. StackOverflow is amazing for Q&A: it has a reputation system, voting, the ability to mark a question as answered. Because of the reputation system it is likely the community will see and answer your question there. This also helps us use the GitHub bug tracker for bugs only. Will close this as this is really a question that should be asked on SO. |
facebook-github-bot
added
the
Ran Commands
|
@satya164 I assume that you closed this issue because you thought this was a question. However, I persist that this is a bug. This is not a configuration issue. Unless you think JSX bundle serving does not need to be supported on Linux, I believe this issue belongs to Github. Please unclose this issue. |
|
@daesan thanks for being persistent, I think you are right, this does seem like a bug, I'll reopen it. Would you want to try building an earlier version between 0.21 and 0.22 and bisect where the break happened? We'll need to make releases more often to make it easier for the community to find issues like that. And sorry for a bad experience, GitHub does not give enough tools to manage an open source project. |
|
@bestander Thanks for reopening this issue! Sure. I am definitely willing to dig into this issue. However, I am not familiar with the process of building React Native from the source. Could you point me to the document or tutorial explaining how to go about this? I understand that maintaining a popular project like RN is a lot of pain and appreciate people doing it. Thanks for being responsive. :) |
|
@daesan You can open the UIExplorer.xproj in XCode and build from there. |
|
@satya164 I checked out 0.21-stable branch. Could you explain me how I can pick individual commits and apply selectively? Is this how I am supposed to do this? |
|
@daesan This is going to be painful :( I think you can use |
|
@satya164 I have tried to work with "git bisect", but I am having a lot of difficulties. More of individual commits seem to break the build. And maybe I am just not very familiar with git but there doesn't seem to be a simple way to apply individual commits either. Do you think this brute force method of finding the offending commit is really the best way to proceed with this issue? While I am not very familiar with most of the native codes of RN, this seems to be a networking issue. Only difference I can think of between JSX bundle being served on my MacBook and Linux server is that MacBook is accessed via IP address and Linux server is accessed via domain name. Do you think this could be at the core of the issue, maybe? Or could you identify someone who is more familiar with this part of RN code base? |
|
@daesan, to make your life easier, these are the commits between 0.21 and 0.22 You should be able just to |
|
It should take 8 steps to pin point the broken commit |
|
@bestander Thanks for printing this out! I will try to identify the offending commit. |
|
Thanks for not giving up, @daesan. |
|
@bestander Hey, thanks for bearing with me on this issue. ;) Being able to alternate among different commits would definitely help a lot on issues like this! From the commits list you gave me, I tried to sample them and build my app with them. For some reason, first commit record (b051d07 Update CONTRIBUTING.md) already broke the build. I got the error "Command /bin/sh failed with exit code 1" on XCode. (This puzzles me a little. Shouldn't this build without problem since it's almost identical to 0.21.0-stable?) First commit that did build successfully, that I found, was "eb53194 Fix the last imports of I tried to sample several commits between "b051d07" (first commit) and "eb53194" (the one that builds), but none of them builds successfully. The following is the list: f6b0c13, 00178b7, 2957f73, cf0c3d4, c8835d0, a759131, 54a423e, 9148620, f9e81d9, 97c799a I am not sure how to process from here on. Do you have any suggestions? Thanks! |
|
@bestander Hey, this doesn't quite make sense. Commit eb53194 is merely a changes to JS files. Why would this commit fix the build? Does the commits list you shared above strictly in order? |
|
@bestander Okay. I spent all day and found out that the offending commits are the followings: dab24b4, f9e81d9. The commit title is "Enable persistent socket between packager and bridge" but it doesn't have any detailed explanation. How should I proceed from here on? Should I try to communicate with the author of the commit? |
|
Thanks so much @daesan! |
|
@daesan awesome job, thank you! As a temporary workaround, can you try setting your |
|
@frantic Ah, that's what "(null)" part meant in the debugging console. Can't believe I missed that! Thanks for sharing that workaround! :) By the way, could you explain briefly what that commit does? Is it related to Hot Reloading? |
|
@frantic I applied the workaround you suggested. However, when I run my app, I get the following error with red screen on iPhone:
If I "reload JS", this error goes aways and reloading works without any problem, until I restart the app. On the console of the server(npm start), I get the following error:
Also, if I "Enable Live Reload", I get the following error with red screen on iPhone:
|
|
@daesan, for the first error message ("Websocket connection..."), what port is your packager running on? The packager defaults to (8081), so unless you're using a custom port, can you try that port instead of 80 to workaround the bug? |
|
@bottledwalter Got you. I tried 8081 and it works without any errors. Please let me know if I can be of help for debugging. |
|
@frantic @bottledwalter Regarding the second error message ("locals[0] does not..."), it turns out that this happens only when I disable |
Summary:The packager url for the persistent connection relied on a port in the bundleURL, so we need to insert a sensible default. Otherwise, issues occur: #6581 Reviewed By: bestander Differential Revision: D3113034 fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145 fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
|
@bottledwalter has landed a fix. Please reopen if this still doesn't work. Regarding hot reloading, I'm pretty sure it will not work with |
|
@frantic Thanks for letting me know. Running from "0.23-stable", I can now use port 80 for JSX bundle loading. However, "Hot Reloading" still does not work. I applied @bottledwalter's patch above (3226b59). It does not seem to help. Could you reopen the issue? I don't seem to have that privilege. |
Summary:The packager url for the persistent connection relied on a port in the bundleURL, so we need to insert a sensible default. Otherwise, issues occur: #6581 Reviewed By: bestander Differential Revision: D3113034 fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145 fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
Summary:The packager url for the persistent connection relied on a port in the bundleURL, so we need to insert a sensible default. Otherwise, issues occur: facebook#6581 Reviewed By: bestander Differential Revision: D3113034 fb-gh-sync-id: 4eac52631ad7abd343b75a4488bb591b5caf2145 fbshipit-source-id: 4eac52631ad7abd343b75a4488bb591b5caf2145
|
This issue has been stale for a while with a bunch of folks submitting things to fix it, so I'm going to guess it's fixed and closed it. If this is still a problem then feel free to reopen. |
I am hosting JSX bundle on the linux server so that my teammates can test the latest version of the app I am working on.
Up until RN 0.21 I had no problem. However, starting with RN 0.22 I am getting the following error on XCode when my app starts and tries to fetch the jsx bundle from the server.
On the debugging console, I have following values.
URL NSURL * @"http://app.xyz.com:(null)/message?role=shell" 0x000000015f53f690cookies NSURL * @"http://app.xyz.com:(null)/message?role=shell" 0x000000015f53f690Looking at the server console (npm start), HTTP request message to the bundle file is printed only some of the times. I assume that is due to the asynchronous nature of such requests.
Does anybody know why this error is occurring? Could this error be related to the HMR, newly introduced in RN 0.22? Any feedback will be appreciated!
The text was updated successfully, but these errors were encountered: