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.
Top comments (1)