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

Absolute path guide #1712

Closed
wants to merge 3 commits into from

Conversation

@louisgv
Copy link

commented Mar 4, 2017

Guide to add absolute path configuration, according to the last comment from #741

Update README.md
Guide to add absolute path configuration.
@@ -346,6 +346,35 @@ Learn more about ES6 modules:
* [Exploring ES6: Modules](http://exploringjs.com/es6/ch_modules.html)
* [Understanding ES6: Modules](https://leanpub.com/understandinges6/read#leanpub-auto-encapsulating-code-with-modules)

## Importing a Component using path relative to src (Absolute path)

Create a file called `.env` in the root of the project, then add the following:

This comment has been minimized.

Copy link
@viankakrisna

viankakrisna Mar 5, 2017

Contributor

.env is exists in .gitignore. So anyone that is collaborating will not have the file and need to do this in the project. I think this setting should not exists in .env. Can we tell them to install cross-env and do cross-env NODE_PATH=./src react-scripts start in .scripts in package.json instead?

@gaearon can we make the NODE_PATH configurable in package.json? 😄 So the user can just set it once and be done with it.

This comment has been minimized.

Copy link
@Timer

Timer Mar 5, 2017

Collaborator

I believe there was an argument posted somewhere on these issues arguing to check .env into source control, as it doesn't contain any secrets (client side code shouldn't).

I don't believe we're going to add new configuration for this, however.

This comment has been minimized.

Copy link
@viankakrisna

viankakrisna Mar 5, 2017

Contributor

Yeah, but i believe that .env should contain the environment specific setting like CHOKIDAR_USE_POLLING which doesn't need to turned on in specific env. This env variable is making the codes in src directly dependent to have it setup.

So, this would cause confusion if the docs says it like this right now. For example, when the original author push it to a git repo and other team member tries to clone it, the repo is not working in other team member local machine because of the missing .env files. And we have "it's working on my local machine" problem all over again.

I think right now If we want to document NODE_PATH in the docs we need to use the cross-env in the scripts, or make it configurable.

The officially supported ways of making an absolute import is discussed here #1065 so I think that this pr would be better to document that instead.

This comment has been minimized.

Copy link
@gaearon

gaearon Mar 5, 2017

Member

I believe there was an argument posted somewhere on these issues arguing to check .env into source control, as it doesn't contain any secrets (client side code shouldn't).

Yes, we'll remove it from gitignore as part of #1344.

This comment has been minimized.

Copy link
@viankakrisna

viankakrisna Mar 5, 2017

Contributor

Ok then, I'm not aware of this. Just experienced an "it's working on my local machine" because of .env that's is missing. :)

This comment has been minimized.

Copy link
@ttjkst

ttjkst Mar 14, 2017

But why not it doesn't work when I use 'npm start ' to run my project ?

This comment has been minimized.

Copy link
@gnapse

gnapse Mar 25, 2017

Contributor

I recall that Rails' dotenv (which takes care of loading this .env file in a rails app environment) was able to recognize several .env files, like .env, .env.local, .env.development, .env.production, etc. I think this would fix this issue. The settings to be checked into source control live in .env, where a comment can specify that any other settings needed only by a specific developer in their local environment should be set in the .env.local file instead.

@gaearon

This comment has been minimized.

Copy link
Member

commented Mar 5, 2017

#1344 will remove .env from .gitignore. But in the meantime (and for people with existing projects after #1344 landing in a release) we should add a sentence saying "Make sure to remove .env from your .gitignore in the project root" and do so for every section that asks to put something in .env.

louisgv added some commits Aug 20, 2017

@louisgv

This comment has been minimized.

Copy link
Author

commented Aug 20, 2017

Derp... I totally forgot about this PR.

@gaearon

This comment has been minimized.

Copy link
Member

commented Jan 9, 2018

Eh. I feel like we should just figure out fixes necessary for #1333 instead of promoting this approach. Thanks for PR though!

@gaearon gaearon closed this Jan 9, 2018

@lock lock bot locked and limited conversation to collaborators Jan 20, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants
You can’t perform that action at this time.