I noted this a few years ago, before ".env" became the norm, but the effect was the same. People were putting their OAuth keys into configuration files, committing them to git, and a bot search came across several thousand exposed keys just looking for Amazon's. Similar numbers probably would have been found with google and others.
In that case, I wanted to make sure that my users knew where to put their stuff, so I created a credentials.template file that showed the format, and that got committed, but my own credentials did not. One could do the same here by having a README.env.txt file to document what to do, and cat that file to the console in an npm post-install hook.
The negative of that, though necessary, is it means you're not distributing running code. They can't just pull your files down and npm start and everything works. They have to finish the init by creating their own files. It may also complicate automated testing systems that would have to be configured to provide that file before running.
If you have made this mistake already, one possible way to fix it is to interactive rebase back to the sha that introduced the problem, wipe the file and add the .gitignore line there, and then deal with the merge conflicts as it pushes the rest up if you ever had to touch that file again (either in format or in updating the data in it).
Of course, how much work that is depends on the age of your code (how many commits and how many branches).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I noted this a few years ago, before ".env" became the norm, but the effect was the same. People were putting their OAuth keys into configuration files, committing them to git, and a bot search came across several thousand exposed keys just looking for Amazon's. Similar numbers probably would have been found with google and others.
In that case, I wanted to make sure that my users knew where to put their stuff, so I created a credentials.template file that showed the format, and that got committed, but my own credentials did not. One could do the same here by having a README.env.txt file to document what to do, and cat that file to the console in an npm post-install hook.
The negative of that, though necessary, is it means you're not distributing running code. They can't just pull your files down and npm start and everything works. They have to finish the init by creating their own files. It may also complicate automated testing systems that would have to be configured to provide that file before running.
If you have made this mistake already, one possible way to fix it is to interactive rebase back to the sha that introduced the problem, wipe the file and add the .gitignore line there, and then deal with the merge conflicts as it pushes the rest up if you ever had to touch that file again (either in format or in updating the data in it).
Of course, how much work that is depends on the age of your code (how many commits and how many branches).