util.parseEnv and --env-file keep a leading UTF-8 BOM in the first key #67102

Version

v24.18.0 (the code is the same on main)

Platform

Windows 11 x64 (not platform-specific; the file bytes are what matter)

Subsystem

dotenv (--env-file, util.parseEnv)

What steps will reproduce the bug?

printf '\xef\xbb\xbfA=1\r\nB=2\r\n' > .env
node --env-file=.env -e "console.log(process.env.A, process.env.B)"
node -e "console.log(require('util').parseEnv('A=1\nB=2'))"

Such files are common on Windows: PowerShell 5.1 Set-Content -Encoding utf8 / Out-File -Encoding utf8 and Notepad's "UTF-8 with BOM" write a leading EF BB BF.

How often does it reproduce? Is there a required condition?

Always, when the file starts with a UTF-8 BOM.

What is the expected behavior? Why is that the expected behavior?

1 2 and { A: '1', B: '2' }: the BOM is an encoding marker, not part of the first key. The dotenv package returns { A: '1', B: '2' } for the same bytes, and Node already skips a BOM when loading CommonJS/ESM sources and JSON.

What do you see instead?

undefined 2
{ B: '2', 'A': '1' }

The first variable is silently lost under its real name.

Additional information

Dotenv::ParseContent (src/node_dotenv.cc:147) strips \r but not a leading BOM, so it stays in the first key. Skipping a leading \xEF\xBB\xBF at the start of the input there would fix both --env-file and util.parseEnv. This also affects tools that moved to util.parseEnv, e.g. Vite's .env loading.