Skip to content
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

how to access the homepage /path from within the app? #956

Closed
godmar opened this issue Oct 25, 2016 · 13 comments
Closed

how to access the homepage /path from within the app? #956

godmar opened this issue Oct 25, 2016 · 13 comments

Comments

@godmar
Copy link

godmar commented Oct 25, 2016

In the documentation it says to use the 'homepage' property in package.json to produce builds that are not mounted at the server root.

How do I access the pathname portion of this property in the application?
I need to use it, for instance, inside <Route> declaration:

<Route path={?homepage.path?} .... />

Similarly, when interacting with react-router's functions, I need to access it.
I'd like this to be DRY. Thank you.

@gaearon
Copy link
Contributor

gaearon commented Oct 25, 2016

It is exposed to the code as process.env.PUBLIC_URL.

@gaearon gaearon closed this as completed Oct 25, 2016
@godmar
Copy link
Author

godmar commented Oct 25, 2016

Thanks. It's a bit surprising that what looks like a node.js process environment variable is available on the client. What does 'process.env' represent, logically? A snapshot of what the node.js process environment was when webpack ran? Or the 'process.env' environment when client-side code runs? Is this documented somewhere?

In any event, process.env.PUBLIC_URL is not set during development (I do see process.env = {} though.)

So I require special casing for development and production, like const mountPoint = process.env.PUBLIC_URL ? splitPathNameFromURL(process.env.PUBLIC_URL) : '/'?

Would be nice if I could access this more simply and have it work in both production and development. Accessing the current URL mountpoint seems a frequent operation (?)

@gaearon
Copy link
Contributor

gaearon commented Oct 25, 2016

Thanks. It's a bit surprising that what looks like a node.js process environment variable is available on the client.

It's a very common practice called "envifying".

What does 'process.env' represent, logically? A snapshot of what the node.js process environment was when webpack ran?

Yes.

Or the 'process.env' environment when client-side code runs?

No, this is impossible with static builds.

Is this documented somewhere?

Yes, in the User Guide, just like everything else. So is PUBLIC_URL.

In any event, process.env.PUBLIC_URL is not set during development (I do see process.env = {} though.)

It should be. If it's not, then this is a bug.

Are you sure it's not an empty string? (Which would be expected in development.)

So I require special casing for development and production, like const mountPoint = process.env.PUBLIC_URL ? splitPathNameFromURL(process.env.PUBLIC_URL) : '?'?

No, if it's missing it's a bug. However it will be the pathname, you don't need to split anything. So it should be an empty string in development.

Would be nice if I could access this more simply and have it work in both production and development. Accessing the current URL mountpoint seems a frequent operation (?)

Definitely, and PUBLIC_URL should give you exactly that (if not, it's a bug).

@gaearon gaearon reopened this Oct 25, 2016
@godmar
Copy link
Author

godmar commented Oct 25, 2016

I suspect it's a bug then.

console.dir shows an empty process.env, and in the minified code it says:

... process.browser = true;\nprocess.env = {};\nprocess.argv = [];  ...

which appears to come from this line

@godmar
Copy link
Author

godmar commented Oct 26, 2016

Upgrading to 0.7.0 fixed it, presumably because of PR #807

@godmar godmar closed this as completed Oct 26, 2016
@gaearon
Copy link
Contributor

gaearon commented Oct 27, 2016

Which version were you on? (There's a reason the issue template asks for the version.)

@godmar
Copy link
Author

godmar commented Oct 27, 2016

0.6.1.

Remember I didn't file this issue as a bug, but as a how-to question. When you said it could be a bug, the first thing I did was to check whether I use the most-up-to-date version, as I do before I file any bug.

Let me add one suggestion. From the documentation, it's not clear that the package.json's homepage setting and the PUBLIC_URL are related. Especially since "homepage" already has a different meaning in npm.

Perhaps fix by adding a sentence: "The value specified in homepage will be made available through the PUBLIC_URL variable", and link to the "PUBLIC_URL" section.

@gaearon
Copy link
Contributor

gaearon commented Oct 27, 2016

Sounds reasonable. Would you like to submit a PR for this?
The only change I'd make is to clarify it's not the whole homepage, but the pathname.

@godmar
Copy link
Author

godmar commented Oct 27, 2016

No thank you.

I don't have your repo cloned, and submitting a PR for a 1 sentence change means at least 3 min of work for me when it would mean 30s of work for you. Also, I don't want to sign the facebook contributor agreement, and in general I feel I'm doing enough (without pay) for FB here by helping to debug and improve your product, and, more importantly, by teaching it to students. Or at least trying to, given the constraint that a 30 day old version fails documented functionality ;-)

On a technical note, I don't understand why a project "homepage" is the same as the production build deployment target. You probably shouldn't be using the "homepage" property for this (?)

@gaearon
Copy link
Contributor

gaearon commented Oct 28, 2016

I don't have your repo cloned

You can edit documentation on GitHub.

Also, I don't want to sign the facebook contributor agreement

This project has no CLA as far as I know.

in general I feel I'm doing enough (without pay) for FB here by helping to debug and improve your product, and, more importantly, by teaching it to students

It's your call, sure. I do appreciate your work. As you can imagine, I also have a ton of other issues to take care of including in React itself, and this project is largely driven by community contributions.

You probably shouldn't be using the "homepage" property for this (?)

For now, that ship has sailed. We could change it at some point when we introduce our own configuration format but we've been avoiding decisions about it for now. I think we may introduce optional streamlined configuration in several months, and then we'll consider making it more explicit.

@wfehrnstrom
Copy link

wfehrnstrom commented Aug 24, 2018

@gaearon thank you for CRA's good documentation on this matter. I'm afraid I'm still confused as to what the expected behavior of process.env.PUBLIC_URL is. I have a few questions. I've built my react-app using yarn run build, and then serve it with serve -s build. My code that relies on the public URL is used for fetching images to be displayed in a photo grid, where I specify the loading path as:
const loadPath = process.env.PUBLIC_URL + '/img/';
In my directory structure, img is immediately beneath the public folder. I check for the public url path using
let fullFilePath = loadPath + jsonImg.filename; console.log("FULL FILE PATH: " + fullFilePath);
and my output is then
FULL FILE PATH: /img/cold_stream.jpg
As you have stated, process.env.PUBLIC_URL is set during the build process and should be set. However, PUBLIC_URL looks to be an empty string. Why might this be? I have not messed around with the ENV variables of this project or set homepage in package.json. Thank you for your help.

EDIT: after running create-react-app --info, my version of react-scripts is 1.1.4. This should satisfy the documentation's requirement of react-scripts ^0.5.0. I am running this build on localhost:5000.

@godmar
Copy link
Author

godmar commented Aug 24, 2018

PUBLIC_URL looks to be an empty string. Why might this be?

Because by default you're at the root.

@wfehrnstrom
Copy link

wfehrnstrom commented Aug 24, 2018

Yes thank you, so this makes sense. so then is there a reason why my image is not resolving? It is served from the server root, at /img/cold_stream.jpg

EDIT: figured it out! thanks!

@lock lock bot locked and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants