I'm trying to move all the sensitive variables to .env file. It works just fine server side on Node but I'm having trouble doing it with React.
I referenced these answers: this and that
1.I changed my .env so it looks like this
REACT_APP_SIGNER_PK = xxxxxx-xxxxx-xxxxxx
Added the variable itself to the file containing script
const REACT_APP_SIGNER_PK = process.env.REACT_APP_SIGNER_PK;
Placed .env inside of my root folder
I restart the server after the changes with yarn run dev
To test out the changes I put this print statement from the file where I put the env variable in
console.log(REACT_APP_SIGNER_PK);
On the restart of the local server I check the console and in the terminal where the server is running I see the print statement with my environmental variable, but in the browser console I see this print as undefined
The only thing that differs in my action from the references is that I use yarn run other than npm start
What did I do wrong?
Thanks to the comment from #OFRBG I managed to find a solution.
Adding REACT_APP_ app to the my .env variables did not work because I was using nextJS instead of Create-React-App.
In order to fix the problem this problem for nextJS users add NEXT_PUBLIC_ instead as a prefix for your .env variables
Related
I'm having trouble setting up my project to use a local meteor package instead of a "remote" one. The meteor package I'm trying to use locally is a copy of meteortesting:mocha (so I can put my own logs into it).
Here's what I've done:
Git cloned the meteortesting:mocha repo onto my machine
Copied the repo into my project root folder with cp -r [PATH]/meteor-mocha **.**
Set METEOR_PACKAGE_DIRS=./meteor-mocha
But when I run meteor add meteortesting:mocha (which is the name of my local package in ./meteor-mocha/package/package.js) it still adds the registered/online meteortesting:mocha package instead of finding my local one.
I also tried fooling around with the name of my local package (i.e. name:"meteortesting:mochalocal") to differentiate it, but when I ran meteor add meteortesting:mochalocal it gives the error "error: no such package"
Does anyone know why this may be the case? I based my set up on this article
I know I can also try to put it in ./packages, but I wasn't sure how to approach that with this repo because it's more than just a package.js folder.
UPDATE 9/12:
Here is what I've tried (which doesn't work) with adding my local package to ./packages:
You can use the ./packages folder inside your project. Copy the package folder inside this. Then you will have:
./packages/meteortesting:mocha
Or you can use another folder to your packages. Example:
/home/my_packages
Then set this:
METEOR_PACKAGE_DIRS=/home/my_packages
Then your package will be in this path:
/home/my_packages/meteortesting:mocha
Hi I'm trying to create a Discord bot using Discord.js and deploy it to Heroku.
I have successfully deploy it to Heroku, but the logs shows an error. Here is where I think the problem is:
app[worker.1]: Error: Cannot find module './config.json'
config.json cant be found because i put the config.json file inside a .gitignore file. This is because i have some credentials (bot token) that i need to protect inside that file. However, the main file needs access to the config.json in order to run.
Is there any way to still protect the contents of the config.json file while still being able to run the program? The GitHub repository is set to private, so should i exclude config.json from .gitignore instead?
If it's just a small side project, and your GitHub repository is private, there should be no issue in leaving the config.json out of your .gitignore. However, for larger or open-source projects, you can use Heroku's config vars, and that should do the trick. I recommend using config vars but if you just want to throw your code up on Heroku, leaving it out of .gitignore should be fine. I would recommend config vars though, they work reliably.
Thanks,
Jackson
You should use environmental variables to save tokens. Then you change your config.json to point to those environmental variables, and not the actual token.
More info on how Heroku does env variables here:
https://devcenter.heroku.com/articles/config-vars
(I'm assuming it's not having issues finding your config because it's looking for config.json when the file is actually named config.js or vice versa)
The issue
I'm working on an application that uses the dotenv package.
It's not currently setting any of the environment variables when I run yarn test or yarn start I'm getting errors because the environment variables are not being set.
App.js has this line near the top of the file
require('dotenv').config(); - there are no references to process.env before this line of code is called.
Things i've tried
Install dotenv globally.
Completely delete the node_modules folder and rerun yarn install
Providing the environment variables manually (this actually worked, but I've confirmed with another developer that the tests and the app is running just fine on his system without having to provide the environment variables manually.
App.js (entry point)
7 require('dotenv').config();
.env (entry point)
LOG_LEVEL=testlevel
APP_NAME=testapp
TestController.js (consumer)
const log = logger(process.env.LOG_LEVEL, process.env.APP_NAME, 'TestController');
I'll take any help I can get at this point.
Ok, figured it out. Apparently the server was actually being started by mocha and there was a reference in there to process.env that was the problem. After adding the require('dotenv').config() to the beginning of the server file, the problem was resolved.
Thanks guys!
I changed the filename of one of my routes from authroutes to authRoutes. When I commit the changes and deploy to heroku, the build fails because it is still looking for authroutes.
2017-09-16T15:57:57.744695+00:00 app[web.1]: Error: Cannot find module './routes/authRoutes.js'
The only reference to the file is in my index.js file via:
require('./routes/authRoutes.js')(app);
I make the change in the index.js file when committing. I've tried clearing my build cache with the heroku-repo plugin as well as making changes to the file itself. If I switch the file name back as well as the reference in index.js, everything works without a hitch. I've tried manually changing the file with heroku bash but it just switches back after the build process is completed to the all lowercase version.
Thanks!
The buildpack may be doing something with the hash comparison against the repo that requires a change bigger or more significant than a single byte changing Case.
If that is so, why dont you try a drop/add of an entire file across 2 successive git push actions?
rm your router file from project
git push heroku master ( node start may fail but so what )
add back your "new" router file with the change that the repo hash failed to recognize
git push heroku master with the new version of the router
that should fool the buildpack hasher for node projects enough to FORCE thru your change.
I have a local development machine and a test server.
Now I have an APP_ID that's being used in Javascript. I've been looking into ways that they kan differ on my local machine and on the test server.
Using Gulp
With gulp it's possible to add a flag on the command line:
gulp build --env=production
That way I can get the correct APP_ID from a file.
The only issue is with this approach I need to run my build on the server, at this moment I run gulp locally and upload the changes to my server
Is it okay to build on the server? Are there other ways to use environment variables in Javascript?
My suggestion is to not build on the server but build locally and then deploy to the server using one of the many deploy solution (es. deployer.org for php). Normally javascript NPM packages put build output even in GIT repository ready for use in other projects or for deploy.
For more info on how to use env variable in node (gulp run over node) see this page
For example in linux you can set env variable with export
app.js :
console.log(console.log(process.env.foo))
Then try
> export foo=app1
> node app.js
Res:
app1
Then try
> export foo=app2
> node app.js
Res:
app2
This is valid only if you run your code server side on node (ex on gulp).
If you are developing a client side library and you want to create different builds that targets different enviroments you have to instruct gulp to do so. In this case this is a guide that can help you