Coming back to typed 100% AWS Lambda API’s, I’m convinced the config module is an anti-pattern if you’re using TypeScript.
Been away from typed server-side for about 4 years. While the 1st I had ReScript on the back-end in Amplify, the rest of the companies I was at did JavaScript/Python. In those languages, dynamic, sleek, easy to use global variables are nice for smaller projects with quick deploys.
Like types? Nope; all the allure dynamic languages have for “use a global proces.env.NODE_ENV to grab some dev.json that is magically inherited from default.json” suddenly screams “Why is this all un-typed, un-parsed without Zod, not wrapped in a Result, and why is config not used via dependency injection? Globals… in 2025?”
Then you realize… you don’t even need anything beyond some simple types + 1 helper function, and you’ve got a type safe, environment aware configuration.
First define your default config, equivalent to config’s “default.json”.
Second, define your dev and prod config, extending the default (both in types and in values).
Finally, create a get method, passing in process so you can unit test it with a stub vs. using it as a global variable. An improvement would be to pre-parse NODE_ENV so you don’t need a default in the switch.
JavaScript, I’m fine with the config module. In TypeScript, it’s dangerous and shouldn’t be used in Node.js.