Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.20.1
      npm: 9.8.0
      Yarn: N/A
      pnpm: N/A
    Relevant Packages:
      next: 13.4.12-canary.0
      eslint-config-next: 13.4.12
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.3
    Next.js Config:
      output: standalone

Which area(s) of Next.js are affected? (leave empty if unsure)

Standalone mode (output: "standalone")

Link to the code that reproduces this issue or a replay of the bug

https://github.com/gchallen/environment-variable-parsing-problem

To Reproduce

Run next build in a project with a symlinked .env file (and that has certain tokens).

Describe the Bug

.env file parsing seems to have changed in a recent version of NextJS, which is breaking our builds which worked previously. Here's an example error output:

Found configuration in /Users/challen/www/cs124.org/rush.json

- info Loaded env from /Users/challen/www/cs124.org/sites/cs124/.env.local                                                                   [37/1958]
- info Loaded env from /Users/challen/www/cs124.org/sites/cs124/.env.production
- warn You have enabled experimental feature (outputFileTracingRoot) in next.config.js.
- warn Experimental features are not covered by semver, and may cause unexpected or broken application behavior. Use at your own risk.

- info Linting and checking validity of types
Failed to compile.

../../.env.development
Module parse failed: Unexpected token (7:17)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/conc
epts#loaders
| SEMESTER=Summer2023
|
> NEXTAUTH_URL=http://localhost:1124
...

There are similar errors in .env.production.

I figured that I could work around this by adding some quoting in places that either NextJS or webpack wanted it. But this problem is also preventing the use of commented-out settings, since it doesn't seem to accept (and ignore) lines started with #. This is a bit of a more serious problem, since given that some of our .env files are not checked into version control, it's important from a sanity perspective to restore the names of disabled settings so they can be enabled and disabled without forgetting what they are called.

This seems to have cropped up in NextJS 13.4.11, or at least 13.4.10 is the latest working version.

Perhaps there is a way to exclude these files from the build once their values have been loaded by NextJS, so that webpack doesn't trip over them? .env.development in particular isn't even being used in the build process.

After a bit more poking around, this seems to only be triggered when the .env file is symlinked into the NextJS build directory. Please see the reproduction repository for an example. Note that it has an extra level of directories to allow the symlink into the root.

Expected Behavior

NextJS should build the project correctly.

Which browser are you using? (if relevant)

Chrome

How are you deploying your application? (if relevant)

Other platform (local infrastructure via Docker container)