-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
serve bundles and app under homepage path #1887
Conversation
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks! If you are contributing on behalf of someone else (eg your employer): the individual CLA is not sufficient - use https://developers.facebook.com/opensource/cla?type=company instead. Contact cla@fb.com if you have any questions. |
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
with this pr can we pass full url as example: import logo from './logo.svg';
console.log(logo);
console.log(process.env.PUBLIC_URL); command:
what I expect:
|
Can you please re-add the relevant tests from #937? |
@smmoosavi that command currently doesn't work off of the master branch either, so i'm not expecting it to work with this. with that command, off of master even, it tries to open the browser with but the result when you open the correct url is
under this branch, minus the issue of the command, it prints out
and when you add a homepage with a sub folder:
|
I synced with upstream master. @smmoosavi @Timer is that command supposed to work then? |
It's ok for me. In development I always close I use cra only for static files (e.g. |
@kellyrmilligan there are tests in that PR that were never merged which check for PUBLIC_URL to be respected on |
another solution: adding condition only if |
What should happen if I visit |
Visiting a subpath like http://0.0.0.0:3000/wow/asd/ appears broken (I set This breaks any apps relying on client-side routing. |
Files in the I would expect that the files in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d love to get this feature in but we need to fix the bugs:
- Subpaths below the main subpath shouldn't 404
public
folder should serve from main subpath rather than from the root- Opening the root should redirect to the main subpath
It is important that you test this pull request thoroughly, and carefully check how different existing CRA features are affected by the new behavior.
It also appears that the end-to-end test is failing. I'm not sure why, but it looks like it never prints Anyway, I appreciate your work on this so far! I'm afraid I'll have to push this back to 0.11 because I need to cut 0.10 very soon, and unfortunately this feature is not ready. |
There's yet another use case I'd like to bring up if possible: the Do you all think it is possible to namespace that as well? Right now, it's still trying to find it under root, which unfortunately does not work with my reverse-proxy set up. Thanks :) |
Good point, I agree any root paths should be namespaced in this case. (Including the new stack frame overlay path.) |
yes, I need that as well. I thought in my current change it is doing that,
but I may be incorrect. i've made some progress today on this and will
continue to chip away at it this week.
…On Mon, May 15, 2017 at 10:48 AM, Dan Abramov ***@***.***> wrote:
Good point, I agree any root paths should be namespaced in this case.
(Including the new stack frame overlay path.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1887 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AChQqIl807UHQqjfsmYC0ikna6oPFmA8ks5r6HPWgaJpZM4Mm0dn>
.
|
ok, I have the following working locally:
going to run the tests and fix the conflict and push back up. |
I guess I'm okay if we serve 404 on other paths. As long as it's not a 500. |
Hmm I don't think so. It should match the way you expect it to work in production. The public is treated as a root but served as a subpath. |
It's been so long I'm not sure I fully understand the entire problem here anymore [or my old concerns]. I remember we had concerns on how At this point in the game, I think it's best to get this to a functioning point, merge it, and then identify pain points and resolve them in a future breaking release. |
I’m using this right now in day to day dev team of 3, and its working well. Again the main drawback is if you’re using behind a proxy and a sub path, then auto refresh won’t work. I’ll look into the response above to see if there’s more I can do |
It seems they're killing off |
@Timer not a correct assumption there 😄 webpack-dev-server will exist in perpetuity and continue to accept fixes. |
Well that's good!
Can we get a small expansion on this, or is it a secret? 😛 |
@Timer DM me on twitter or invite me to a slack and I'll give you all the dirty deets |
@shellscape cool to see a clean break and re arch of web pack dev server. From what I can tell with the current wds, we can’t establish a sock js node connection under the root, is that correct? |
@kellyrmilligan its like fight club. what's the first rule 😄 The sockJS implementation is a mess. It takes the best guess as what it should be set at, but there are bugaboos all over the place with that. I'd like to forget about it. It haunts my dreams 👻 |
Meant @gaearon |
I think I'm fine with this trade-off on first-ship since we're going to coordinate our release very tightly with the new hotness. I don't think we're really worse off than our current position anyway (it just doesn't work now, so we might as well half work). |
@Timer synced with master just now. |
@kellyrmilligan @Timer fwiw |
@shellscape I'm subscribed to the repo and have been keeping a close eye. I'm sorry for not being more responsive; I'm going through a role change at work right now so my work is sort of doubled down until the transition is complete, thus a lack of time. |
@Timer zero worries my dude! taker care of that IRL and if the opportunity presents, let me know when and if I can help. |
@Timer do you want to use the new serve module for 2.0 or to get my pr updated for this next release then do it? |
this is now in #4158 |
What was the status of this? The PR mentioned seems to have died, and this got moved to 'Nope' ? |
@peterbraden See #4158. |
Hi, I was referring to the last comment on that PR: "Thanks for this. I am at a new job now, and with webpack 4 this PR is now old and need to be redone. I think at this point i need to let this PR die yet again" Not sure how the issues tracker works on this project, but if the issue is closed and the PR dies I wanted to ask if this would fall through the cracks? Thanks! |
I believe at some point create-react-app is going to support this feature but there is no ETA. #4158 is part of the milestone 2.0.0 so rest assured it's not going to fall through the cracks :) |
Hi, did this feature make it into @bugzpodder do you have any insight into this? |
Verified by adding homepage to package.json, and confirming that it would display the subpath in the terminal, and open the browser with the sub path in the url.
tested by editing both js and css to verify hot loading works the same as before.
Then verified that if I take homepage back out of package.json, it works as intended.