feat(core): add .env support to Configuration

[jj811208]

What's the problem this PR addresses?

Closes #4718
related issue: #2724
related PR: #3938

Typical use case is for NPM auth tokens that may differ from a project to an other, you want them to be stored locally in your project rather than in a .bashrc file for example.

I agree with this point because my project has the same problem.

I'm not sure about other use cases for env in yarn, but I guess as long as yarnrc.yml supports .env, it should solve most of the use cases

• This PR does not load .production.env, .development.env, .test.env..., only .env
• When there are multiple yarnrc.yml in the project, each yarnrc.yml will load both the .env in the same directory and the .env at the root of the project.

How did you fix it?

1. install the dotenv@16.0.2 package 5ed9434
2. new Configuration private method - findPackageEnv 630a7c9
3. let the parseXxx family of functions accept env parameters 1f961ba
4. yarnrc.yml load the .env file 1374abb
5. expose environment information in the Configuration ec7ed66
6. new test about the feature d5870bb d9f7ca9

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[jj811208]

I think this will conflict with #4912, so I'll change its state back to draft first~

after #4912 is merged, I will come back to resolve the conflict and reopen 🙂.

[jj811208]

#4912 is merged 🎉!!

So I came back to this PR.

It has been more than a month since this PR was created, and during this period, I have been following yarn issues and yarn discord,

but I still don't see any use cases that need multiple .yarnrc.yml 🧐,

I think such use cases are quite rare, not to mention multiple .yarnrc.yml and multiple .env use cases,

so I think that I did originally over-design 🙈,

for these rare use cases, I made the code more complex, making the review more difficult and increasing the chances of breaking change in the future,

I prefer to make it simpler now.

---

I made the following changes:

1. Rename findPackageEnv to findProjectEnv and put it in miscUtils

Although the names are similar, I personally think the package smells like a dependency, and I couldn't find the reason why I made it a configuration method before🙃

2. No longer reads the .env from each workspace

This use case is too rare

3. No longer put .env in configuration.values

I think we can read .env in this way miscUtils.findProjectEnv(cwd), although inconvenient, but it can prevent breaking change and we can decide on a better way to get it in the future.

4. environmentSettings can also read .env now

I missed this before

5. Make parseSingleValue pure, pass in env from outside

I think making it a pure function, putting process.env and projectEnv in the same place to make this code easier to read.

6. Not supported for the lockfileFilename property

1. To make `.env` work for `.yarnrc.yml`, we need to read the project's `.env` first.
2. To read the project's `.env`, we need to get the project's directory first.
3. To get the project directory, we need to get `lockfileFilename` first.
4. To get the `lockfileFilename` name, load `.yarnrc.yml` first.
Loop... so I finally use `DEFAULT_LOCK_FILENAME`

---

If there is a clearer need for .env in the future, I would be happy to work on it again 😃.