'Basic Node and Express - Use the .env File' - .env should be removed from .gitignore

Contributors
1

Tell us what’s happening:

The test was initially not passing for me, I spent 2 hours:

  1. Debugging my code and changing it.
  2. Checking my .env.
  3. Checking forum posts.

All the checks was a waste of time. My code was correct to begin with and I was investigating a red herring. The problem was resolved when I simply removed .env from .gitignore (which was in the boilerplate by the way).

The tutorial does not tell me to do that, so this was an incredibly frustrating experience. In fact, the tutorial told me that .env is a secret file. So logically I didn’t know I was supposed to commit it and push it to my repo. Yet this is the pass criteria for the test?

Unless I am missing something here, I think the best solution is to remove .env from.gitignore in the boilerplate github repo: GitHub - freeCodeCamp/boilerplate-express: A boilerplate for the freeCodeCamp curriculum.. But instruct students that this is not what you should normally do.

Am I missing something here? I really hope I am missing something here and it’s not the fault of the tutorial, but it seems to be that way.

Your code so far

require("dotenv").config();
let express = require("express");
let app = express();

console.log("Hello World");

const pathToIndex = __dirname + "/views/index.html";

app.use("/public", express.static(__dirname + "/public"));

app.get("/", function (req, res) {
  res.sendFile(pathToIndex);
});

app.get("/json", function (req, res) {
  if (process.env.MESSAGE_STYLE === "uppercase") {
    res.json({ message: "HELLO JSON" });
  } else {
    res.json({ message: "Hello json" });
  }
});

module.exports = app;

Your browser information:

User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0

Hosting is on render.com.

Challenge Information:

Basic Node and Express - Use the .env File

2

Hello there,

If I understand correctly, you are working on this project locally, and deploying to render.com. The deployment is possibly being done through Git (pushed changes cause a deployment)?

If so, this is expected behaviour. Any file in the .gitignore will not be tracked by Git.

That said, most projects I have ever worked on (over 100) have a .env file, and include it in the .gitignore, because this file is used for secrets that should not be pushed to a public repository.

You will encounter this in the following projects where you will be asked to add your database URI to the .env file, which, if you make public, someone can access your database.

Essentially, this boils down to the way you are hosting/deploying your project. This is case-specific. So, the instructions cannot include information for every single host/provider/workflow.

I assume render.com have a way to add secret/environment variables, and you will have to search how to do so in order to be able to pass.

Hope this clarifies

3

Thanks for getting back to me Sky.

If I understand correctly, you are working on this project locally, and deploying to render.com. The deployment is possibly being done through Git (pushed changes cause a deployment)?

If so, this is expected behaviour. Any file in the .gitignore will not be tracked by Git.

That said, most projects I have ever worked on (over 100) have a .env file, and include it in the .gitignore, because this file is used for secrets that should not be pushed to a public repository.

Yes that’s right and yep I know about that already. I had already pushed the .env file to the repo to pass the test. With your advice, I need to go back and check a more secure way with Render.com.

So, the instructions cannot include information for every single host/provider/workflow.

I understand what you’re saying. At the same time, surely we can do more to signpost the newbies? For example, the course could literally have one line that says ‘You may have to check secrets instructions with their provider to solve some of the challenges’ (but phrased better). This would’ve saved me time if I knew the right place to look in the first place.

You will encounter this in the following projects where you will be asked to add your database URI to the .env file, which, if you make public, someone can access your database.

Actually I am at this stage right now, so your reply came at the right time. As I mentioned, it would be even better if the student is informed ahead of time e.g. check with your provider about the secrets, .env vars.

To summarise: I want confidence that another fcc student doesn’t have to go through the same frustration as me. Constantly checking my code when nothing was wrong with my code to begin with.

1 Like
4

Thank you. That is useful feedback.

The main thing we are trying to work with is:
a) Learners do not read - this is the first rule of web-design/tutorial-creation
b) We expect anyone who does not make use of the “simplified” setup (i.e. Replit) either already knows what they are doing, or will take the time to learn the specific tool they are using

For now, I suspect we will not be making major changes to this curriculum, because we are in the process of replacing it with a new version.

That said, adding a line like you suggested would not be a major change.

1 Like
5

Thanks Sky, I feel happy that I am being heard.

For now, I suspect we will not be making major changes to this curriculum, because we are in the process of replacing it with a new version.

Interesting, I was about to ask where is the suitable place to post suggestions if I feel the wording can be improved (or just any feedback to the current curriculum). But maybe I don’t need to do that, if there will be a new version in the future?

6

Often, the best place is as an issue in the “main” repository: GitHub - freeCodeCamp/freeCodeCamp: freeCodeCamp.org's open-source codebase and curriculum. Learn to code for free.

Otherwise, if you are in any way unsure of the suggestion, then here on the Contributors sub-forum works well.

If someone opened a pull request making that single line change, I would accept it. That said, we are very soon going to make changes to the introduction of that lesson, in preparation for the new curriculum. So, with this in mind, and probably an issue to track it, we can do it all together.

1 Like