#TFW the appropriate response to a tool in your build chain going out of support is to just... Delete it, without replacement.
@Nentuaby But ~*~ automation ~*~!!! ;P
@Nentuaby I'm currently dealing with an issue similar to this in my 2005-vintage codebase. Because of automation and custom frameworks that we've standardized on, we're stuck on old libraries, and security is poking at us now to upgrade from these vulnerable dependency versions.
I'm beginning to develop a nervous tic now, that triggers a disgust reaction when I hear things like "automation" and "code generation" :).
@Nentuaby Sounds like it was a v. useful tool!
@hummingrain It would've been (until it sunsetted, of course) if they'd actually... Used it. But instead they half-refactored to use it only in the iterative dev cycle, while the _production_ build still had an independant source of truth that had to be kept hand-synchronized with it, making the whole thing an active detriment. 
@hummingrain So now we're just "replacing" a whole-ass multimegabyte vendor package management behemoth with a template file full of CDN script tags. That was there the whole time.
If there's one lesson I've learned from working on this demon-haunted codebase, it's *don't* modernize your tooling unless you're actually prepared to commit to hunting down and completely decommissioning whatever you're replacing.
Also, really genuinely consider whether you need a tool to generate a config file from your codebase, or whether maaaaaybe it will actually be easier in the longrun to just maintain a config file.