allow usage of .env file for PAT tokens

[wolfcomp]

This fixes where PAT tokens aren't loaded fast enough for retrier to see them if using a .env file.

This is aimed for when you want to deploy this project for your self and not use vercel.

[vercel]

@wolfcomp is attempting to deploy a commit to the github readme stats Team on Vercel.

A member of the Team first needs to authorize it.

[qwerty541]

Hey, @wolfcomp! Thanks for your pull request! Looks like current code and the one inside incoming changes do exactly same, i have doubts that replacing it before all imports will significatly affect on anything. But i see recommendation on dotenv package page "As early as possible in your application, import and configure dotenv:". It is hard to judge for me how useful is this changes since i have never deployed github-readme-stats without Vercel like all other core team members. I'm okay to give my approval on this pull request if you can provide link on your deployment to be sure that it works.

[wolfcomp]

My deployment is just pulling the project from GitHub and creating the PAT_1 token in a .env file and then afterwards run node express.js inside an Ubuntu screen instance with a Nginx reverse proxy in between which is running on my own server box at stats.wildwolf.dev
and as you can see with top-langs output:

[vthwang]

Hello,

I'm currently trying to follow this PR. I'm using a custom Dockerfile to build the latest code. However, I encountered an issue with the message "No GitHub API tokens found. Please add an environment variable called PAT_1 with your GitHub API token in Vercel."

Essentially, I faced the same problem as the one addressed in this PR. Once I made the modifications suggested in the PR, it worked flawlessly. We should definitely delve deeper into this PR to understand the details.

Thank you so much for the effort! 😄

[wolfcomp]

The reasons I believe it isn't an issue on Vercel is that it registers it as a systemwide environment variable, which is accessible before the connection processing happens for how many tokens it has available for rotation if rate limited.

Essentially I traced it down to this being run before the .env file was loaded, which caused it to think when no variables are registered in the system table that it doesn't have one ever even if it loaded later.

And yes @qwerty541 I read the recommended documentation for dotenv to see how it forced the load compared to the normal method, as even if I just moved the lines for loading the file above the rest of the import statements it still didn't function properly, which from the looks of it is due to every function invoke in JavaScript being async.

[qwerty541]

The reasons I believe it isn't an issue on Vercel is that it registers it as a systemwide environment variable, which is accessible before the connection processing happens for how many tokens it has available for rotation if rate limited.

Essentially I traced it down to this being run before the .env file was loaded, which caused it to think when no variables are registered in the system table that it doesn't have one ever even if it loaded later.

And yes @qwerty541 I read the recommended documentation for dotenv to see how it forced the load compared to the normal method, as even if I just moved the lines for loading the file above the rest of the import statements it still didn't function properly, which from the looks of it is due to every function invoke in JavaScript being async.

@wolfcomp If i correctly understand you, this changes don't completely resolve the problem, just making it occures less often, environment variables still can be not loaded in time.

Did you tried to make this import syncronous with top-level await?

await import ("dotenv/config.js");

I think it worth to try, i found it there:
https://stackoverflow.com/questions/74436886/how-to-have-synchronous-es6-imports

[wolfcomp]

And yes @qwerty541 I read the recommended documentation for dotenv to see how it forced the load compared to the normal method, as even if I just moved the lines for loading the file above the rest of the import statements it still didn't function properly, which from the looks of it is due to every function invoke in JavaScript being async.

@wolfcomp If i correctly understand you, this changes don't completely resolve the problem, just making it occures less often, environment variables still can be not loaded in time.

Did you tried to make this import syncronous with top-level await?

await import ("dotenv/config.js");

I think it worth to try, i found it there: https://stackoverflow.com/questions/74436886/how-to-have-synchronous-es6-imports

@qwerty541 With the import "dotenv/config"; that is included in this PR the first thing to load is the .env files in the same directory as the file. This is because it is treated the same way as what you linked but a higher version of ECMAScript in this case ES2020.

The main difference is that you are either importing a CommonJS module into ES module which is allowed with just import "module";
Where if you want to import a ES module into a CommonJS module you would need await import("module")
Both work the exact same way, and only what module type you are in matters for the syntax.

Reference related to TypeScript error becasue of this import difference

[qwerty541]

And yes @qwerty541 I read the recommended documentation for dotenv to see how it forced the load compared to the normal method, as even if I just moved the lines for loading the file above the rest of the import statements it still didn't function properly, which from the looks of it is due to every function invoke in JavaScript being async.

@wolfcomp If i correctly understand you, this changes don't completely resolve the problem, just making it occures less often, environment variables still can be not loaded in time.
Did you tried to make this import syncronous with top-level await?

await import ("dotenv/config.js");

I think it worth to try, i found it there: https://stackoverflow.com/questions/74436886/how-to-have-synchronous-es6-imports

@qwerty541 With the import "dotenv/config"; that is included in this PR the first thing to load is the .env files in the same directory as the file. This is because it is treated the same way as what you linked but a higher version of ECMAScript in this case ES2020.

The main difference is that you are either importing a CommonJS module into ES module which is allowed with just import "module"; Where if you want to import a ES module into a CommonJS module you would need await import("module") Both work the exact same way, and only what module type you are in matters for the syntax.

Reference related to TypeScript error becasue of this import difference

@wolfcomp Ok, thanks for your explanation. I'm approving this pull request since the code follows recommended way of dotenv package usage, your deployment works well and @TingSyuanWang confirmed that this solution helped him. I requested reviews from other project maintainers, we can merge pull request when it receives one more approval.

[rickstaa]

Hey @qwerty541, considering that this pull request aligns with the recommended ESM syntax outlined in the dotenv documentation, I'm all for merging it. Go ahead and merge it if it runs smoothly on your local machine.

[qwerty541]

Hey @qwerty541, considering that this pull request aligns with the recommended ESM syntax outlined in the dotenv documentation, I'm all for merging it. Go ahead and merge it if it runs smoothly on your local machine.

@rickstaa I tested this branch on my local machine and it works well. Merged into master, thanks for approval!

@wolfcomp Thanks for your contribution!