I assume this is DOA given the comment in the README:
I feel strongly about maintaining backwards compatibility for people who rely on it, so any PRs would also need to adhere to keeping the API sane, or contribute to some improvement in performance
Since it changes some of the core APIs, if didn't want to do a major version bump, it would need to be a different package. Some of the design choices (eg. preference for functional over OOO) aren't compatible. For the moment I renamed it dename and published it that way for a project, however wanted to throw it back to see if there is any desire to incorporate it into the original project.
Future goals are creating some pluggable components, like a db connector, recursor, zone file parser, etc. as separate packages.
I assume this is DOA given the comment in the README:
Since it changes some of the core APIs, if didn't want to do a major version bump, it would need to be a different package. Some of the design choices (eg. preference for functional over OOO) aren't compatible. For the moment I renamed it
denameand published it that way for a project, however wanted to throw it back to see if there is any desire to incorporate it into the original project.Future goals are creating some pluggable components, like a db connector, recursor, zone file parser, etc. as separate packages.