goatandsheep/react-native-dotenv

.env overrides .env.xxx

bytesoverflow opened this issue · 6 comments

My understanding is that .env should be overridden by .env.xxx which it does when using safe mode, but when safe is set to false the order in which dotenv.config is called should be reversed.

Currently the order in which the files are loaded are: modeLocalFilePath, modeFilePath, localFilePath, path
This means that modeLocalFilePath is overridden by modeFilePath which is overridden by localFilePath which is overridden by path

dotenv.config({
      path: modeLocalFilePath,
      silent: true,
    })
    dotenv.config({
      path: modeFilePath,
      silent: true,
    })
    dotenv.config({
      path: localFilePath,
      silent: true,
    })
    dotenv.config({
      path: options.path,
    })

Should the order not be: path, localFilePath, modeFilePath, modelLocalFilePath?
This means that path is overridden by localFilePath which is overridden by modeFilePath which is overridden by modelLocalFilePath

dotenv.config({
      path: options.path,
    })
    dotenv.config({
      path: localFilePath,
      silent: true,
    })
    dotenv.config({
      path: modeFilePath,
      silent: true,
    })
    dotenv.config({
      path: modelLocalFilePath,
      silent: true,
    })

Hey, thank you for opening this issue! 🙂 To boost priority on this issue and support open source please tip the team at https://issuehunt.io/r/goatandsheep/react-native-dotenv/issues/348

I definitely need to fix this!!

note this will be released later

Hi, Thanks for taking a look. I'm not convinced that the order should be inverted, I think the following test proves that to be incorrect (the env value from .local is overridden).

.env

SOME_VALUE='from .env'

.env.local

SOME_VALUE='from .env.local'
const dotenv = require('dotenv')

dotenv.config({
  path: '.env.local',
  silent: true,
})
dotenv.config({
  path: '.env',
  silent: true,
})

console.log(process.env) // prints SOME_VALUE: 'from .env' expecting SOME_VALUE: 'from .env.local' 

Ignore my previous comment - the problem seems to be related to the zsh dotenv plugin on my machine, when i disable the plugin the inverted behaviour works as expected.

Thanks again.