If you can afford using a package manager then you can afford using something more sophisticated than bash.
The whole point of bash is that it’s ubiquitous: be it an air-gapped embedded system, a recovery image or a full desktop environment, you can count on it having either bash or something reasonably close, no strings attached.
Introducing a Rube Goldberg package manager would go against this.
I can see in the use case of building up scaffolding between many different Unices to a common reference point sufficient to serve as an abstraction layer for a packaged software product to code against a generic Unix model, a Bash package manager might be useful. Some of those Bash-based abstraction layers can get relatively sprawling, and a packaging system would serve a useful role as a configuration dispatcher.
Instead of a bewildering array of case/if statements for each architecture/distro in every script, the package manager stores and deploys the platform-specific scripts, and make reading/maintaining them more streamlined. Then your case/if selection of the platform-specific environment is centralized into a single centralized location where the package manager call for installation is made.
I agree however that in an in-house setting, if I had the choice to use a package manager, then I'd be choosing a language other than Bash.
> bpkg is a lightweight bash package manager. It takes care of fetching the shell scripts, installing them appropriately, setting the execution permission and more.
> You can install shell scripts globally (on /usr/local/bin) or use them on a per-project basis (on ./deps/), as a lazy-man "copy and paste".
Also bash-lib is using bats (Bash Automated Testing System) for verification, which is un-maintained and has been forked should anybody be interested https://github.com/bats-core/bats-core
Interestingly, the legacy debian-installer is based on a package manager called anna (Anna's not nearly Apt), where most of the installation steps are implemented as postinst bash scripts of various udeb packages: https://salsa.debian.org/installer-team/anna#README
However, there's little documentation for any of this, and it's clearly not intended to be used for anything outside of the installer context— I couldn't even figure out how to do the equivalent of a debootstrap for an anna environment. For my own custom installer needs it turned out to be easier to use a conventional deb/apt environment and implement most of the logic in Python.
At my company, for what we deploy as Bash, we take care to write it according to regular software engineering standards (code + tests + doc), build OS-specific packages, distribute them using proper repos (rpm, deb) and bake them into vm machine images/containers where needed. We declare dependencies between packages to specify (versioned) dependencies between different code libraries. Works for us.
Looking at how e.g. some official AWS code is written and distributed in shell (like ec2-instance-connect-config), that's not too far I guess from how even big orgs handle Bash code.
(If you had told me in 2001 that Javascript would have had NPM and bash not, I would not have believed you.)