For Release 0.3, we are working on modernizing the Plant CDOT feed. The current site looks like this http://zenit.senecac.on.ca/~chris.tyler/planet/. The new project is primarily written in node.js and is now focused on getting key functionality implemented. The pull request that I worked on involved creating the initial config file. After doing some research I found that the config file contains environment variables. I learned that environment variables are important when developing a project, because they allow your app to preform differently based on the environment. Some common places to use the environment variables are for the application host, port, db credentials, etc. When attempting this issue, it was suggested that I use the dotenv module. Dotenv loads environment variables from a .env file into the process.env property (object containing the user environment). This makes using environment variables fairly easy throughout the project.
After doing some research, I found that I needed to first add the .env file into the .gitignore file, so that sensitive information wasn’t exposed when pushing to github. Then I had to create a template .env file that contained default data for our application. So far, I added NODE_ENV and PORT variables and set them to the default configuration. Whenever a developer wants to run the project, they will copy the template env file and replace all the default values with their credentials and rename the file to .env. From here, I had to include a config file that required and configured dotenv. Whenever environment variables are needed, the config file must be required.
When I posted my PR, there were really helpful comments. Someone suggested I use .env_example instead of .env_sample, which is better practise. I also got feedback on creating documentation so that developers understand how to use the .env file and using comments to serve as documentation in the .env_example file.
After making a few changes, it got merged!
I also made a smaller PR request, because I noticed that when I ran the ESLint test for my initial pull request there were some errors in the dialogue.js file.
As for discussions within the project, I did some research for sending emails to admin feature and suggested using nodemailer. For release 0.4, I’m thinking of collaborating with the person assigned to this issue. I think I might be a larger feature to implement. I also, reviewed two PRs. The first was to silence npm logs and the other was to integrate the redis url into the .env file.
So far this project has been fun, I can’t wait to see how it transforms in the next release.