Repository navigation
Removal of the @types/config package downgraded type safety #913
Description
Describe the bug
Regarding the removal of the external @types/config package. While I'm fully in support of packages managing their types locally instead of through DefinitelyTyped, the decision did sadden me a bit since the new V4 types removed a lot of the type safety that I introduced in #70288.
I do acknowledge that the types I added in that PR were prone to TypeScript performance issues, particularly if any types were recursive, but I have since refined my approach to typing dot notation expressions and would really love to see that kind of type safety brought back to node-config.
I'm more than happy to make a PR that restores these type definitions, but I wanted to first check to see if the maintainers are interested in this or if they no longer wish to have this kind of type safety.
Activity
markstos commentedon May 23, 2026
Are the performance issues during development or runtime? If only development, seems reasonable to try them again.
TurtIeSocks commentedon May 23, 2026
The performance issues were only experienced during type resolving in development, and for the most part, it only happened if your config definition included complex recursive types. 0 impact on runtime.
jdmarshall commentedon Jun 3, 2026
Is there a path to improve the type definitions now in node-config to reduce this discrepancy?
jdmarshall commentedon Aug 20, 2026
For background, I believe the real reason we moved toward removing those was that we were starting to have a reasonable type definition of our own, but there was also no clear road to handling the semver-major changes that were and are in process.
There was no version I could see that supported the LTS and 5.0 versions at the same time, and the same may happen with 6, which I'm hoping to be fully ESM (with an async top level)
Fix node-config#913
TurtIeSocks commentedon Aug 20, 2026
@jdmarshall I forgot that I wrote the fix for this last month and never opened a PR :)