DEV Community

Discussion on: You are reading environment variables the wrong way in Next.js

yatki profile image
Mehmet Yatkı • Edited on

Actually I really like this approach. It sounds like a best practice to me.

I have library to read environment variables as application config. I was thinking to add it to the library, having an option like mandatoryKeys but then I left it to users to validate the keys. Maybe adding that option and making it mandatory to define could force this practice. If they don't want to validate the keys they'll have to define mandatoryKeys: [] for instance. I'll think about it.

GitHub logo yatki / read-env

🔧 Transform environment variables into JSON object with sanitized values.


Transform environment variables into JSON object with sanitized values.

NPM version npm Coverage Status Dependencies

See docs for previous version v1.3.x.

Main purpose of this library is to allow developers to configure their applications with environment variables. See: a use case example.

What's New with v2.x 🚀

  • Migrated to Typescript, Yay! 🎉
  • Simplified API
  • With new separator option,nested object constructions are possible.
  • New source option allows you to use other objects, other than process.env

Migrating from v1.x to v2.x

  • default export is deprecated. Please use named export readEnv as below:
const { readEnv } = require('read-env');
// Or
import { readEnv } from 'read-env';
// Or in browser
Enter fullscreen mode Exit fullscreen mode
  • parse option was renamed as sanitize.
  • transformKey option was renamed as format.
  • Deprecated options: ignoreInvalidJSON, prefix, filter,


npm install --save read-env


yarn add read-env


Thanks for the tip.

Cheers, 🚀🖖