I wanted to give the community a heads up about the roadmap for the next major release of node-config. Given the feedback on deletions in the 4.2 code I wanted to make sure nobody got any unpleasant surprises.

Toward ESM

The main goal of 5.0 is ESM support. This is an overdue feature request, with a long list of reasons that it was not done sooner.

The dominant issue at this point is that the Turing Complete config file types that node-config supports need to load node-config to utilize a number of features, while node-config is itself still loading. Self-recursion is essentially a bug according to the ESM module specification, which does not at all like re-entrancy during module initialization. Because of this, there are some rather substantial chunks of node-config 3.3 that simply cannot work as an ESM module. A number of contributors have made attempts to fix this and other issues over the last few years. I've tried enough times myself that I've lost count. I think this is my third attempt, but I suspect it's actually my 4th.

The good news is that this one seems to be sticking. I had a branch that worked with the defer and async replacements, and I don't anticipate any additional problems with RawConfig since I'm handling it identically to DeferConfig. At this point all of the ESM-friendly replacements - except RawConfig - have been merged to the trunk and the ESM-hostile version has been marked as deprecated, either in 4.3 or the just released 4.4 which I anticipate to be the last minor release of 4.X.

However, all of that jostling of code has turned up a handful of other worrisome bugs, particularly with makeImmutable, which turns out does not make the config particularly immutable. It's a gray area because fixing this bug doesn't violate the design contract of node-config, but could break existing users so that will be yet another breaking change that will go into the 5.0 release.

5.0 Prerelease

There's enough different ways that node-config is initialized, particularly on mixed CJS/ESM projects, and with the potential breaking changes, I have no illusions that we will be able to get everything right on a 5.0.0 release, without a prerelease pipeline to let people shake it out. I believe I finally know all of the hidden features I've never used, but I've also said that before. So I'd rather not try. So I will be doing alpha patch versions of the 5.0 series in order for people to experiment, and file bug reports before they have to upgrade. I'm hoping this dress rehearsal can shake out the worst of the issues.

LTS

According to the published social contract, we should wait a year from deprecation of a feature to removal, but that essentially means no ESM support until February 2027 at the earliest and I don't want to sit on that sort of functionality for 12 months, nor the associated PRs for 10+ months.

I would much rather commit to maintaining a 4.4 branch for the duration, than delay 5.0 to an arbitrary 12 months after 4.4.0 is published. I'd like people to have more runway to upgrade to 5.0 on their own schedule, with 4.4 support ending at that point in time. I suspect that will be a complete non-event at any rate. There aren't many dependencies to generate CERT advisories, the current open bugs themselves require breaking changes and so any PRs are likely to go onto a 5.0 or 6.0 release at any rate. I'm not anticipating a lot of PRs needing to be applied both to an LTS branch and to trunk, and I'm a dab enough hand at complex merges that I can sort out 90% of what you folks can throw at me and we can delay or port the rest.

4.4 has now been released, and a PR has been submitted to begin the 5.0 alpha.